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ABSTRACT 


Rapid prototyping is a method of software system development that is gaining 
much support presently. Rapid prototyping allows the designer to quickly produce a 
model of a system or part of a system which the user can see and thus verify if his re- 
quirements have been met. The prototype specifications can then be efficiently con- 
verted to an accurate set of program specifications that the programmers can 
implement as a final working system. The computer aided prototyping system 
(CAPS) is a rapid prototyping system that will automate many of the processes of 
prototyping such as code generation of prototype modules and searching for reusable 
components. 

One of the many components of CAPS 1s a language translator which translates a 
prototype specification written in the Prototype System Description Language 
(PSDL) into a set of Ada procedures and packages. The Ada procedures and packag- 
es, when executed in proper order, will effectively execute the prototype. This thesis 
demonstrates an implementation of the translator component of the CAPS. An at- 
tribute grammar tool, Kodiyak, is used to build a translator which implements the ma- 
jor constructs of PSDL and produces Ada code to implement PSDL operators 


according to their control constraints. 
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I. INTRODUCTION 


Rapid prototyping is the process of producing a model of a software system to be 
evaluated by the system designer and the system user. It is becoming a widely ac- 
cepted method for software systems design. In a conventional systems development 
cycle the system designer and the user work together to determine a set of user re- 
quirements and goals for the complete system. These are eventually converted into a 
set of specifications which can be implemented in a particular programming language. 
If all goes well, the system is implemented according to the specifications and is thus 
a true implementation of the user’s requirements and goals. 

Unfortunately, systems development is much more difficult than this. Rarely is it 
the case that the designer successfully captures the user’s true requirements. Ordi- 
narily, the designer is knowledgeable of computer systems and programming but not 
of the user’s specialty. The same holds true of the user, he knows his application and 
how it should operate but he knows very little of computers and their capabilities. 
Consequently, it is difficult to capture the true requirements of the system for several 


reasons including: 


- The designer is prone to misinterpretation of the user’s goals because they are 
unfamiliar to him. 


- The user often states his goals and requirements in overly general terns. 


- The user may completely omit other goals and requirements simply because they 
are obvious to him while they are not obvious to the designer. 


- Because of his unfamiliarity with computer systems and their capabilities, the us- 
er may not be aware of some features that are available until later in the project 
as he becomes more famuliar with the system. [Ref. 1] 


Whatever the reason, the end result is an incomplete set of requirements that the 
designer must formalize into a set of specifications to be implemented in software. 
Programmers implement the system and it is presented to the user but rejected be- 
cause it does not functionally represent what the user thought he wanted in the first 


place. The user points out the discrepancies and then the designer attempts to 


re-analyze the user’s requirements, form an updated set of specifications, then the 
system is re-implemented, and presented again to the user. This software develop- 
ment loop continues until a version of the system is finally accepted by the user. 

Software systems today are becoming extremely large and complex. Utilizing 
methods such as that described above to construct modern software systems results 
in unreasonably long development life cycles and unreliable systems. Productivity 
must be improved to produce such systeins in a reasonable amount of time today. A 
method must be found that will allow the user and designer to produce a complete and 
accurate set of requirements prior to code generation of the actual system. Rapid pro- 
totyping 1s such a method. 

The rapid prototyping loop shown in Figure 1 replaces the conventional software 
development process. In rapid prototyping the user and designer still perform a re- 
quirements analysis but now a software model of the system, or part of the system, 1s 
quickly assembled and executed for the user instead of a complete system. The model 
is constructed knowing that it is probably going to be altered over and over, however 
new models can be produced quickly so the cost of producing the prototype is relative- 
ly cheap. 

The user can evaluate the prototype and point out any discrepancies. The discrep- 
ancies are soon corrected and a new prototype is available for the user to evaluate. 
This prototype loop continues until the user 1s satisfied with a particular version 
[Ref. 2]. The final prototype can then be used to generate a set of specifications that 
accurately reflect the user’s goals and requirements. Since the programmer is pre- 
sented with an accurate set of specifications, he implements the system once and 
wastes little tume performing code corrections as before. Thus productivity and reli- 
ability are greatly enhanced. 

The computer aided prototyping system (CAPS) is a prototyping system intended 
tO lmprove current prototyping methods by automating tyme consuming tasks in con- 
ventional prototyping such as tuming specifications into prototypes, modifying proto- 
types, and searching for reusable components. The components which make up the 


CAPS system include a specification language, an execution support system, a 


rewrite system, a syntax-directed editor, a software base, a design database, and a 


design management system. 


Determine Construct 
Requirements Prototype 


REQUIRED EXECUTABLE 
MODIFICATIONS PROTOTYPE 


User 
Validate SVE Demonstrate 
he Prototype 


VALIDATED 
REQUIREMENTS 


System | 
Implementation 





Figure 1. Rapid Prototyping Loop 


The specification language (the Prototype System Des .nption Language, PSDL) 
allows the designer to formally translate the user’s requirements and concepts into 
specifications. The specifications can then be used to retrieve reusable software com- 
ponents from the software base. After all of the components of the prototype have 
been retrieved or constructed by the user, they are executed by the execution support 
system (ESS). The ESS is the focus of this thesis. It 1s composed of three systems, 
the translator, the static scheduler, and the dynamic scheduler. PSDL is an execut- 
able specification language whose execution is a combined effort of the translator, 
static scheduler, and dynamic scheduler. The translator translates the PSDL specifi- 


Cations into executable Ada modules while the static scheduler analyzes the PSDL 


specifications and data-flow dependencies to construct a schedule of operation for the 
set of Ada modules with timing constraints. The dynamuc scheduler schedules those 
Ada modules with no timing constraints. [Ref. 3:p. 71] 

Successful execution of a CAPS prototype is dependent on two phases, transla- 
tion and scheduling. The subject of this thesis is the construction of a translator to 
successfully perform the translation phase. The translation process begins with the 
input of a program written in PSDL. The program is parsed into its syntactic con- 
structs, then those constructs are analyzed and Ada code is produced to represent 
them. Translation also means recognizing built-in PSDL constructs and using reus- 
able generic components to implement the constructs. The objective of this thesis is 
the partial implementation of a translator for the CAPS system. 

An overview of the CAPS system components, the Kodiyak application generator, 
and PSDL are presented in Chapter I]. PSDL constructs and their semantic descrip- 
tions are presented in Chapter II]. The implementations of PSDL constructs are pre- 
sented in Chapter IV. The implementation of the translation process will be 


presented in Chapter V. Conclusions are presented in Chapter VI. 


H. BACKGROUND 


A. CAPS OVERVIEW 

The computer aided prototyping system (CAPS) is a rapid prototyping tool pres- 
ently being developed. The objective of CAPS is to reduce a software designer’s ef- 
forts by automating tune consuming tasks in conventional prototyping, such as tuming 
specifications into prototypes, modifying prototypes, and searching for available reus- 
able components. To support this prototyping method, several tools are included as 
subsystems of CAPS which are integrated together to form the functional group called 
CAPS. The components of CAPS include 


- A specification language. 

- A user interface to speed up design entry and prevent syntax errors. 

- An execution support system to demonstrate and measure prototype behavior and 
to perform static analysis of the prototype design. 

- A design management system to manage reusable software components and de- 
sign data. | 

- A software base to store reusable components. 

- A design data base to store the prototype design. [Ref. 3: p. 67-68] 


Figure 2 shows the CAPS system architecture. Following is an overview of the 
functions of each of the components of the CAPS architecture 

The user interface consists of a syntax-directed editor [Ref. 4] and a graphical ed- 
itor [Ref. 5]. These two tools are used together to generate a design which 1s free of 
syntax errors as quickly as possible. The graphical editor allows the designer to en- 
ter his design as a data flow diagram so that relationships between PSDL compo- 
nents can be visualized by the designer and by the user. The syntax-directed editor 
speeds up the process of entering PSDL textual specifications. (Ref. 6:p. 6-7] 

The rewrite subsystem translates the specifications produced in the user 
interface into normalized specifications which can be used by the design management 


System to retrieve components from the software base. Using normalized 


specifications results in fewer keys to use for the search operation on the data base. 
[Ref. 3:p. 69] 

The design management system [Ref. 7] is an object-oriented database manage- 
ment system. It is responsible for organizing, retrieving, and instantiating reusable 
components from the software base as well as managing versions, refinements, and 
alternatives of prototypes in the design database. It provides special purpose opera- 
tions to compose components, browse the software base, and manipulate the normal- 
ized specifications. [Ref. 3:p. 69] 

The software database is an object-oriented software base containing reusable 
components. The software base provides the ability to browse, select, and retrieve 
components efficiently. The database is searched by providing a normalized specifica- 
tion which can be mapped to one or more software implementations. The entire set of 
retrieved reusable components are then presented to the designer so that he may se- 
lect a choice from the set. [Ref. 3:p. 70-71) 

The execution support system provides the means to demonstrate the actual per- 
formance of the specifications produced in the user interface. There are three compo- 
nents of the execution support system, the translator, the static scheduler, and the 
dynamic scheduler. 

The translator generates Ada code to bind together the reusable components ex- 
tracted from the software database. Its main functions are to implement data streams 
and control constraints [Ref. 3:p. 71]. The output of the translator is a set of Ada 
packages and procedures that can be activated in a specific order to effect execution of 
the prototype. 

The static scheduler [Ref. 8] analyzes the data flow structure and control flow 
Structure of the input PSDL program and determines an order of execution, or sched- 
ule, for the PSDL modules which meets the data flow and timing constraints of the 
prototype. 

The dynamic scheduler [Ref. 9] schedules those PSDL modules that have no tim- 
ing constraints. It recognizes when a time slot is available during prototype execu- 


tion and schedules non-time critical modules in those slots. | 
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Figure 2. CAPS System Architecture 


B. PSDL 

The translator’s purpose is to translate a PSDL specification into a set of Ada 
procedures which, when executed in a specific order, will effectively execute the proto- 
type. The translation process is completely dependent on the semantics of PSDL. 

There are several constructs in PSDL that a designer uses to build a prototype 
specification. These constructs include data streams, timers, exceptions, and opera- 
tors. The translator actually builds the operator construct itself during translation, but 
before it can do this, each of the other PSDL constructs must be previously construct- 
ed and available. Construction of a PSDL operator involves instantiating various Ada 
representations of PSDL constructs and manipulating those constructs to provide a 
supporting framework in which a PSDL operator can be simulated. 

1. PSDL Conceptual Model 

PSDL is based on a conceptual model existing as a network of operators and 
data streams. Operators in the network communicate with each other through data 
streams [Ref. 6:p. 11]. An operator is a function which performs a specific user de- 
fined task. It requires a set of input values and produces a set of output values each 
of which may be empty. A data stream is a conduit for moving data values between 
operators. They are the source of an operator’s inputs and they are the sink into 
which an operator places its output. 

PSDL can be represented as a computational model described by an augment- 
ed graph 

G =(V, E, T@), C(v)) 
where V is a set of vertices, E is a set of edges, T(v) is the maximum execution time 
for each vertex v, and C(v) is a set of control constraints for each vertex v. In this 
graph a vertex represents an operator and an edge 1s a data stream. 

Figure 3 is an example of a PSDL graph with operators, A, B, and C, and data 
Streams, a, b, c, d, e, and f, connecting the operators. The graph also indicates timing 
constraints, 10 ms for A and C, 20 ms for B. Control constraints are provided for A 
and B, also. The operator A receives its input data on data stream a, processes the 
data and outputs two results on data streams c and d. This entire process must occur 


in ten milliseconds or less according to the associated timing constraint. 


Normally, control constraints are not described on the graph because they can 
be numerous and are described textually within a PSDL specification. A graph with- 


out control constraints is called an enhanced data flow diagram. [Ref. 3:p. 69] 


Operator A: 
output d if a=c 


Operator B: 
triggered by some b,d 





Figure 3. Enhanced Data Flow Diagram With Control Constraints 


2. Operators 
Operators in PSDL are either functions or state machines. A function produc- 
es output whose value is dependent solely on the input values. A state machine pro- 
duces output whose value depends on the input data values and on internal state 
values. Operators can be triggered by the arrival of input data values on thei data 
streams or by a periodic tiniing constraint which says the operator must fire at a regu- 
lar time interval. 
PSDL operators may also be atomic or composite. “stomic operators represent 
a single operation and cannot be decomposed into subcomponents. A composite oper- 
ator represents the network of subcomponents and data streams into which it can be 
decomposed. [Ref. 6:p. 11-12] 
3. Data Streams 
Data streams represent sequential data flow mechanisms which move data 
between operators. There are two basic types of data streams, sampled and data 
flow. Data flow data streams are similar to first-in-first-out (FIFO) queues with a 
length of one. Any value placed into the queue must be read by another operator be- 


fore another data value is placed into the queue again. Sampled data streams may be 


considered as a single cell which may be read from or wnitten to at any time and as of- 
ten as desired. [Ref. 6:p. 12-13] 
4. Timing Constraints 

Timing constraints are an essential part of specifying real-time systems. 
They impose an order on operator firing which is based on timing or control flow rather 
than data flow. The three basic types of timing constraints are MAXIMUM EXECU- 
TION TIME, MAXIMUM RESPONSE TIME, and MINIMUM CALLING PERIOD. 
The maximum execution time is an upper bound on the length of time from the instant 
when an operator begins execution to the instant it completes. [Ref. 6:p. 20] 

The maximum response time has two interpretations depending on the type of 
operator it applies to. For sporadic operators which have no period, it is an upper 
bound on the length of time between the arrival of one or more new data values on an 
input data stream and the tune when the final output value is placed on an output data 
stream in response to the new input values. For periodic operators, maximum rfe- 
sponse time is an upper bound on the tune between the beginning of a period and the 
time when the last output value is placed onto a data stream of that operator during 
that period. [Ref. 6:p. 20] 

The minimum calling period is a lower bound for sporadic operators on the time 
between the arrival of one set of inputs and the arrival of the next set. [Ref. 6:p. 20] 

5. Control Constraints 

Control constraints are the mechanisms which refine and adapt the behavior of 
PSDL operators. They specify how an operator may be fired (by data flow or control 
flow), how exceptions may be raised, and how or when data may be placed onto out- 
put data streams. 

With the exception of timing constraints, all of the features of the PSDL com- 
putational model will be discussed in detail in Chapters Il and IV. For a more de- 


tauled discussion on timing constraints see [Ref. 8] and [Ref. 10] 
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C. KODIYAK TRANSLATOR GENERATOR 

Kodiyak is a fourth generation language designed for producing language transla- 
tors and prototyping languages [Ref. 1l:p. 1]. It was developed at the University of 
Minnesota and is based on Knuth ’s description of attribute grammars [Ref. 12]. 

Very generally speaking, Knuth wrote that a context-free language can be repre- 
sented as a set of grammar rules and that by systematically applying those grammar 
rules to an input string, the input string can be uniquely represented as an abstract 
syntax tree [Ref. 12:p. 127-128]. Knuth goes on to say that attributes can be as- 
signed to the nodes of the abstract syntax tree and that the values of the attributes 
can be determined in two ways. 

The first method is by synthesized attributes which assigns values to the at- 
tributes of a node based on the attribute values of the node’s descendants. The sec- 
ond method is by inherited attributes where a node’s attribute values are based on 
the attribute values of its parent node. Synthesized attributes are evaluated from the 
bottom up in the abstract syntax tree while inherited attributes are evaluated from the 
top down. [Ref. 12:p. 130] 

The point of Knuth’s paper is that attributes can be assigned to the nodes of an 
abstract syntax tree and those attributes can be defined in terms of other attributes in 
the tree. Thus, the root of the tree can be given an attribute whose value is based on 
the collective values of all the nodes in the tree. That attribute of the root node can be 
used to assign a semantic meaning to the tree [Ref. 12:p. 132] 

Kodiyak puts this theory into practice in three phases. First, it performs a lexical 
anaiysis on the input string converting it to tokens; second, it parses the tokens into 
an abstract syntax tree; and third, it proceeds to move about the tree evaluating at- 
tributes at each node until all attributes have been evaluated. The meaning of the in- 
put string can then be represented as the collective value of the attributes at the root 
node. 

Kodiyak is a UNIX-based tool which is built on top of two other tools, LEX (a lex- 
ical analyzer tool) and YACC (a parser generator tool). Every Kodiyak program has 
three sections. The first section describes the features of the lexical scanner which is 


used to translate the input source text into tokens. The second section describes the 


1] 


attributes assigned to each grammatical part in the language. The third section de- 
scribes the grammar and attribute equations which are used to determine values of at- 
tributes throughout the tree. [Ref. l1:p. 1] 

In the lexical scanner section of a Kodityak program, rules are given which define 
the token terminal symbols of the source language and their token representations. 
Terminal symbols are defined to be regular expressions and are found in the leaf 
nodes of the abstract syntax tree. Token definitions take the form shown in Figure 4 
where TERMINAL NAME is the name of the token and REGULAR_EXPRESSION 
is the definition of the token. For example, two lexical definitions used in this thesis 
are 

OPERATOR “operator” | "OPERATOR" 

SOME "by some' | "BY SOME". 
The first definition defines a token named OPERATOR which is created anytime the 
regular expression "operator" or "OPERATOR’ is found in the input text. The second 
definition defines a token named SOME -which is defined anytime the regular expres- 
sion "by some" or "BY SOME’ its found in the input text. It is by definitions such as 
these, that Kodiyak reads an input text file and converts it to a stream of tokens. 
[Ref. lgp, 2-6] 

The attribute declaration section lists all of the non-terminal symbols in the input 
grammar along with the attributes associated with each symbol. The non-temninal 
symbols are the interior nodes of an abstract syntax tree and are normally found on 
the left side of a typical grammar rule. Kodiyak also allows terminal symbols to have 
attributes if desired. The statements 

psdl {tm : string;}; 
ID { %text: string; 
%oline : int; 
value : int;}; 
are two examples of attribute declarations. The first statement declares a non-termi- 
nal symbol named psdI which has only one attribute named trn of type string. Kodiy- 
ak only supports two primitive types, string and integer. The second example 


declares the attributes for a terminal symbol. An ID token has three attributes, 
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%otext which is type string, Zline which is type integer, and value which is type inte- 


ger. The %line and %text attributes are predefined in Kodiyak. 


TERMINAL NAME : REGULAR_EXPRESSION 


Figure 4. Kodiyak Lexical Definition Form 





The 9%line attribute always contains the line number in the input text where the 
associated token was found. The %text attribute always contains the actual text 
which matched the regular expression definition for the token. [Ref. 11:p. 2-6] 

The final section of a Kodiyak program is the attribute grammar section. This sec- 
tion defines the syntax and semantics of the translation. It consists of a set of gram- 
mar productions in a form similar to BNF and sets of equations defining attributes 
[Ref. 11:p. 8]. The example in Figure 5 is an actual rule used in the translator in this 
thesis. It 1s based on the PSDL grammar rule: 

timer_op ::= READ | RESET | START | STOP 
where timer_op is a non-terminal and READ, RESET, START, and STOP are all ter- 
minal tokens. The rule states that a tumer_op is recognized if any one of the tokens, 
READ, RESET, START, or STOP is found in the token stream. The associated at- 


tribute equations are enclosed in curly braces for each possible rule. 


tumer_op: READ 
{ timer_op.tm = "PSDL_TIMER.READ"; } 
| RESET 
{ timer_op.tm = "PSDL_TIMER.RESET"; } 
| START 


{ timer_op.tm = "PSDL_TIMER.START"; } 
| STOP 
{ tumer_op.tm = "PSDL_TIMER.STOP’; } 





Figure 5. Kodiyak Attribute Equation Example 


13 


The example shows that if tuner_op produces a READ token, then the trn at- 
tribute of timer_op will be assigned the string value of "PSDL_TIMER.READ". 

Without Kodiyak, the implementation of a translator for PSDL would be a much 
more formidable task than it is. Essentially, a lexical analyzer and parser would have 
to be written for PSDL, which are non-trivial tasks, then a tool would be built which 
can traverse an abstract syntax tree and generate code. This would effectively be 
equivalent to writing a compiler for PSDL. Kodiyak allows a programmer to concen- 
trate on the translation process, 1.e., attribute evaluation while it handles the compil- 


er-like functions. 
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Il. MAJOR PSDL CONSTRUCTS 


The constructs used in PSDL include operators, data streams, state variables, 
timers, and exceptions. The execution of a PSDL prototype is actually just the inte- 
gration and manipulation of these constructs according to a set of control constraints. 
With the exception of operators, each of these constructs is represented by an ab- 
stract data type in Ada. The following is an informal discussion of the semantics of 


the major PSDL constructs. 


A. DATA STREAM ABSTRACTIONS IN PSDL 

The edges of the PSDL computational model represent data streams. Data 
Streams are the mechanism by which two or more operators can communicate 
explicitly. Data streams can carry individual data values of abstract data types, 
values of built-in PSDL type EXCEPTION, and values of the built-in data types of 
Ada. Data streams can be described as a pipeline connecting exactly one producer 
with exactly one consumer [Ref 6:p. 12]. 

Figure 6 is an example of a producer operator, opl, connected to a consumer oper- 
ator, op2, by the data stream D. The producer operator has produced the values x1 
and x2 in order. The pipeline property of data stream D dictates that value x! must 
arrive at the consumer operator before value x2 because x] was created first. Anoth- 
er important property of data streams is that they may carry no more than one data 
value at a time. 

When an operator produces a data value, it writes that value onto a data stream. 
When an operator consumes a data value, it reads that value from a data stream 
[Ref. 13]. 

As implied in the previous paragraph, data streams have operations for reading 
them and writing to them. There is also a third operation for checking them to verify if 


there 1s a new, or fresh, data value currently on the data stream. 
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Producer Consumer 





Figure 6. Producer and Consumer Operators 


There are two types oof errors associated with data _ streams, 
BUFFER_OVERFLOW, and BUFFER_UNDERFLOW. BUFFER_OVERFLOW 
occurs when an operator attempts to write to a data stream that currently has a value 
on It. 

BUFFER_UNDERFLOW 1s caused when an operator attempts to read a value 
from an empty data stream. Applying the check operation to a data stream will never 
cause either of these two errors because it neither reads nor writes to the data 
Streain. [Ref. 13] 

There are two basic kinds of data streams, SAMPLED STREAM and DATA 
FLOW STREAM. A sampled data stream has a continuous nature in that once a da- 
ta value has been written onto it, that data value will remain on the data stream until 
it 1S overwritten with another value. Even after a value is read from a sampled data 
Stream, a copy of that value remains on the data stream and can be read as often as 
needed. [Ref. 13] 

Since data values remain on a sampled data stream after they have been con- 
sumed, it is not possible to have a BUFFER_UNDERFLOW error on a sampled data 
stream after it has been initialized once. In an uninitialized state, sampled data 
streams do not have values on them and therefore the BUFFER _UNDERFLOW er- 
ror could occur if a read operation is performed on the data stream before the first 
write operation. The BUFFER_OVERFLOW error cannot occur on a sampled data 
stream at all because the write operation is always legal on a sampled stream. 

Data flow streams have a more discrete nature about them because they are a 
first-in-first-out data structure. A data value can be written onto a data flow stream 


only if the stream is empty, and conversely, a data value can be read from a data flow 
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stream only if a data value presently exists on the stream. After a data value is read 
from a data flow stream, the stream is left empty. [Ref. 13] 

BUFFER_UNDERFLOW and BUFFER_OVERFLOW can be more easily gener- 
ated in data flow streams than in sampled streams because of their first-in-first-out 
nature. Any attempt to read from an empty data flow stream will cause BUFF- 
ER_UNDERFLOW. Any attempt to write to a data flow stream which currently has 
a value on it will cause BUFFER_OVERFLOW. Because of the ease of generating 
these errors in data flow streams, care must be exercised when using them in a proto- 
type. The timing of the producer and consumer operators must be synchronized so 
that the rate of data consumption on a data flow stream is always equal to the rate of 
data production. [Ref. 6:p. 13] 

Whether a data stream is a sampled or a data flow stream is determined implicitly 
by the context in which the stream is used in a PSDL program. Specifically, if a 
stream is used in an operator triggering condition that specifies the operator is trig- 
gered BY ALL, then the stream is classified as a data flow stream. (Operators and 
triggering conditions are described in a later section.) All other data streams not so 
used are sampled data streams by default. 


There are four places to declare data streams in a PSDL operator: 


- In an INPUT statement. 

- Inan OUTPUT statement. 

- Ina STATES statement. 

- Ina DATA STREAM statement. 


Data streaim_visibility within an operator is somewhat hierarchical yet it differs 
from the hierarchical visibility rules that may apply in structured languages like Pascal 
or Ada. In PSDL, data streams which are visible in any operator are also visible to 
that operator’s immediate subcomponents but not necessarily to any of its second 
generation descendants. An operator which has a parent operator can selectively 
choose which data streams in its parent to make visible within itself, thus, if it 
ignores any data stream in its parent, that data stream will not be visible to any of the 


current operator’s descendants. 
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INPUT and OUTPUT statements in a PSDL operator specification declare data 
streams used by an operator which are extemal to that operator. That is, these are 
the data streams belonging to the parent operator which are selected to be visible in 
the child operator. The direction of data flow is dictated by the INPUT and OUTPUT 
statements. An INPUT statement declares that data can only be read from its data 
streams. Likewise, an OUTPUT statement declares that data can only be written to 
its data streams. The forms of the INPUT and OUTPUT statements are shown in 
Figure 7. 

The STATES and DATA STREAM statements are also shown in Figure 7. 
These statements declare data streams that are local to the current operator. The da- 
ta streams declared in the STATES statement are like any other data stream except 
that they are initialized automatically. They are used to carry values of state vari- 
ables which are described later in the discussion of PSDL operators. The DATA 


STREAM statement declares all local data streams that do not carry state variables. 


INPUT id_list : type_name [, id_list : type_name]* 
OUTPUT id_list : type_name [, id_list : type_name]* 
STATES id_list : type_name INITIALLY initial_values 
DATA STREAM id_list : type_name [, id_list : type_name]* 


Figure 7. Method of Declaring Data Streams 


B. TIMERS 
In PSDL, a timer is a built-in data type. The timer data type acts as a simple digi- 


tal stopwatch to record elapsed times. The operations available on timers include: 


- RESET 
- START 
- STOP 
- READ 
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Semantically, a tumer can be described as a state machine (see Figure 8) having 


three states, an initial state, a running state, and a stopped state. 





Figure 8. Timer State Machine 


In the initial state the timer has a value of zero. All timers are initialized to begin 
in the initial state and thereafter will only return to the initial state when the reset op- 
eration 1s performed. 

The timer transitions to the running state whenever the start operation is per- 
formed. The value of the timer in the running state constantly increases with time, 
but its instantaneous value can be obtained by the read operation. 

The stopped state can only be reached from the running state and is done so when 
a stop operation is performed. In this state, the timer is effectively idle and not mea- 
suring elapsed time, that is, its value 1s constant. 

The value of a timer can always be obtained by the read operation. Note that the 
read operation does not cause a state transition regardless of the state in which it is 
performed. The value of a timer is always the amount of time the timer has spent in 
the running state since the last transition out of the initial state. 

Timers are declared inside a PSDL operator by the TIMER statement whose form 
is shown in Figure 9. It is a simple statement that declares any number of PSDL tim- 
ers inside of an operator. Unlike data streams, timers fully utilize hierarchical visibili- 
ty rules. A timer is visible in the operator in which it is declared and all of its 
subcomponents on all levels [Ref. 6:p. 18]. Presently, an implementation restriction 


in this thesis dictates that timer names cannot be duplicated in a PSDL program. 
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All references to a specific timer name throughout a PSDL program are references to 


the same timer. 


TIMER tl, t2,...,tN 


Figure 9. Timer Declaration 


Timer values can be passed along data streams so that a timer’s value can be 
made visible outside of its scope. The timer itself, however, cannot be transmitted 


because it is a state machine, not a value. 


C. PSDL EXCEPTIONS 

PSDL exceptions as described by Luqi in [Ref. 6] are special data types that may 
be written to any data stream regardless of the stream’s normal data type. When a 
PSDL exception 1s raised in an atomic operator it 1s immediately output onto all of the 
operator’s output data streams. This poses a problem in designing downstream oper- 
ators in the data flow. Any time an operator raises a PSDL exception, all operators 
immediately downstream will have a PSDL exception on one or more of their input 
Streams. The designer must consider such a case when writing PSDL operators. A 
PSDL system is a network of atomic operators connected by data streams. Actual 
systems could have very complicated networks. Ensuring that the possibility of a 
PSDL exception value is handled everywhere in the system could be a formidable 
task. 

This thesis describes an alternative method for handling PSDL exceptions. The 
principle difference between this method and Luqi’s is that PSDL exceptions are no 
longer allowed to share data streams with normal data values. An operator must 
explicitly declare any external or local data steams which carry the 
PSDL_EXCEPTION data type. The alternate design is intended to modify the origi- 
nal design of PSDL exceptions as little as possible, given the difference stated earlier. 

Requiring operators to transmit PSDL exceptions only on data streams that are 
declared for the PSDL_EXCEPTION data type means that exception communications 


are now explicit. If an operator is allowed to raise a PSDL exception it can only 
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communicate that exception to operators which are directly connected to it via an ex- 
ception data strean. A PSDL exception handler, therefore, is any PSDL operator 
which has an input exception stream declared in the INPUT statement in its PSDL 
specification. The remainder of this section presents PSDL exceptions in terms of the 
alternative method. 

PSDL exceptions are values of a built-in data type called PSDL_EXCEPTION. 
They are used to denote the occurrence of a value or situation that the designer does 
not want to occur during execution of the prototype. For example, the value on a data 
stream may be out of limits or a data stream may not have a value when it is expect- 
ed to have one. The PSDL_EXCEPTION data type has operations for creating an ex- 
ception, raising an exception, and detecting that an exception has been raised. A 
PSDL exception has two states, raised and cleared. A raised PSDL exception 1s one 
which is active in the same manner that an Ada exception is raised. Conversely, a 
cleared PSDL exception is one that is not raised. 

PSDL exceptions can be raised two different ways. The first is by the 
EXCEPTION statement in an operator’s control constraints. The second method of 
raising a PSDL exception is through an implicit conversion of an Ada exception to a 
PSDL exception. Atomic operators may raise exceptions in the underlying language 
[Ref. 6:p. 19] and the designer has the option of handling the exception in the underly- 
ing language or in PSDL. 

When a PSDL exception is raised it is written to one ~* more data streams. The 
operator which was executing at the time of the exception will be terminated after the 
exceptions have been transmitted. When a PSDL exception is raised in an 
EXCEPTION statement, the designer has control over which streams the exception 
is transmitted. He may selectively choose one or more exception data streams to 
write the exception to. PSDL exceptions raised as a result of an Ada exception are 
not subject to such control. Instead, they are transmitted on all output data streams 
which are declared to be of the PSDL_EXCEPTION data type. If no output exception 
data streams are available in the operator, there is no way of communicating the con- 
verted exception. In that case, the Ada exception is re-raised and handled elsewhere 


in the execution support system. 
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Exception handling in PSDL is not ummediate as in Ada. CAPS places a con- 
straint on prototype execution that adversely affects execution of exception handlers. 
Consider the operation of exception handlers in Ada. When an Ada exception is 
raised, normal execution control flow is interrupted so that an exception handler can 
be located for the raised exception and executed. It is both desirable and good lan- 
guage design, that exceptions be handled immediately rather than allowed to linger 
about in a program. In CAPS, however, execution is bound to a scheduled sequence 
produced by the static scheduler and the dynamic scheduler [Ref. 8] which cannot be 
altered. PSDL exception handlers are not given any special consideration by the 
static scheduler; they are simply operators that are scheduled to execute in a pre- 
defined order, they cannot be invoked immediately as they are needed. Thus, PSDL 
exceptions are allowed to be raised but their handling is subject to the static and dy- 
namic schedules of execution. 

Detecting whether a PSDL exception has been raised is a special operation that 
is performed during evaluation of boolean expressions. It 1s a construct consisting of 
the data stream name containing the exception, followed by a colon, followed by the 
name of the exception. For example, 

OPERATOR a TRIGGERED IF In_Exception : Out_of_Range 
demonstrates a boolean expression which checks to see if the PSDL exception, 
Out_of_Range, is raised on the data stream called In_Exception. The data stream, 
In_Exception must have been declared as an input data stream of type 
PSDL_EXCEPTION in this example. 

A PSDL exception is effectively cleared when it is read from a data stream. A 
PSDL exception is read anytime its value is used in a boolean expression other than 
an operator data trigger. 

PSDL exception visibility follows the same rules as data streams. Any exception 
written to a target data stream is visible only to the operators having access to the 
target data stream. 

It is required to include an exception handler in any decomposition which is capa- 
ble of producing a PSDL exception. Figure 10 shows an example of this technique. 
The operator, A, decomposes into three operators, B, C, and D. Operator B is 
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capable of raising a PSDL exception, thus it has an exception data stream named er- 
ror connecting it to the operator EH. EH 1s an exception handler which is triggered 
by the presence of a value on the incoming data stream. The static scheduler will 
schedule EH to execute sometime after operator B, thus handling the error as soon as 


possible and minimizing the time it is allowed to linger in the system. 





Figure 10. Local Exception Handler 


D. OPERATOR ABSTRACTIONS IN PSDL 

The vertices of the PSDL computational model represent operators. Until now op- 
erators have been only referred to as producers or consumers, however, there is much 
more to an operator than the fact that it produces and/or consumes data. Operators 
are different from the other constructs in that they are not a PSDL type; instead, oper- 
ators are objects which manipulate the other PSDL constructs in unique ways. How 
an operator manipulates PSDL constructs like data streams, timers, and exceptions 


partially defines the behavior of the operator. 
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1. Operator Classification 


PSDL operators may be classified by three criteria: 


- Function or state machine operator. 
- Atomic or composite operator. 
- Periodic or sporadic operator. 


a. Functions and State Machines 

Classifying an operator as a function or a state machine depends on wheth- 
er the operator has an internal state. A function operator does not have an internal 
State. It simply consumes its input and produces an output; the value of the output 
depends solely on the value of the input. Specifically, a function will produce a one-to- 
one mapping from any set of input data values, x1,x2,....xN, to a set of output values, 
yl,y2,...,.yM. A state machine, on the other hand, has an internal state which affects 
the values of its output. A state machine will produce a one-to-many mapping from a 
set of input data values to a set of ouiput values. The value of the output data is a 
function of the input data and the internal state. [Ref. 6:p. 15] 

The internal state in a PSDL state machine operator is represented by a 
STATE VARIABLE. Recall that a state variable is a data stream which 1s automati- 
cally initialized. State variables are declared in a PSDL operator by the STATES 
statement as shown previously in Figure 7. The STATES statement declares a list of 
data streams, which wil be local to the current operator, and a list of initial values to 
be placed into the data streams before the prototype begins execution. A state 
machine can be graphically represented as an enhanced data flow diagram with a self- 
loop as in Figure 11. The self-loop sv1 is the data stream carrying the state variable. 

b. Atomic and Composite Operators 

This classification depends on how an operator decomposes. Atomic oper- 
ators cannot be decomposed into a lower level of functionality while composite opera- 
tors can be decomposed into a set of lower level operators whose execution as a 
whole simulates execution of the composite operator. Figure 12 shows an example 
of a composite operator, A, and its corresponding decomposition into two lower level 


operators, Al and A2. Operator Al is also a composite operator and so decomposes 
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into operators All and Al2. Operator A2 is an atomic operator and cannot be decom- 
posed into any lower level of detail. A PSDL program is nothing more than a hierar- 
chical decomposition of a single composite operator into a network of atomic 
operators. The ordered execution of the atomic operators effectively simulates execu- 


tion of the highest level operator. [Ref. 6] 





Figure 11. Operator With State Variable 


c. Periodic and Sporadic Operators 
This classifies an operator by its timing constraints. A periodic operator 
has tuning requirements which state that the operator must be invoked regularly with- 
in a certain period and that it must complete execution within that period. Sporadic 
operators have no such periodic constraints; instead, they are required to execute 
when there are fresh data on the input data streams. The translator is concerned with 
an operator's behavior as it executes, not how often it executes or how long it exe- 
cutes, therefore, this classification is urelevant to the translation process. For a more 
detailed discussion concerning timing constraints and their implementation refer to 
[Ref. 8]. : 
2. Operator Control Constraints 
To support real-tume systems modeling in PSDL, a powerful set of control con- 
Straints are available which impart a specific behavior upon atomic operators. 
Through control constraints several aspects of an operator’s behavior can be speci- 
fied, such as the classification of the operator, the operator’s tnggering conditions, 
and the operator’s output conditions [Ref. 13]. The translator is concerned with rec- 


ognizing control constraints that have been placed on an operator, which are not 
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timing related, and then generating the Ada code required to simulate the desired op- 


erator behavior. There are four types of control constraints to be specified: 


- Operator triggering conditions. 
- Exception conditions. 

- Timer conditions. 

- Operator output conditions. 





Figure 12. Operator Decomposition 


a. Operator Triggering Conditions 
A triggering condition has two parts, a data tngger and an input guard 
[Ref. 14]. The data trigger is designed to control the initiation of execution of an oper- 
ator based on the presence of new input data values. A new data value on a data 
stream 1s any data value that has not been read at least once. The input guard is a 
secondary condition which makes an operator’s execution dependent on the values of 
its input data. The triggering condition is a means of specifying data flow control 


among operators. The form of a PSDL triggering condition 1s shown in Figure 13. 
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Triggering Condition = 


OPERATOR Atomic_Name TRIGGERED Data_Trigger IF Input_Guard 





Figure 13. PSDL Triggering Condition 


The data trigger part of a triggering condition can be further broken down 
into a BY ALL or a BY SOME condition. Referring to the operator model in Figure 
14, the PSDL statement 

OPERATOR op! TRIGGERED BY ALL A,B 
establishes a data trigger on operator op! that allows it to execute only if there are 
new data values on both of the input data streams A and B. The contents of data 
stream C are not considered in the trigger condition. If either A or B does not have a 
fresh data value then the trigger condition is not satisfied and the operator will not be 
allowed to execute at all. The PSDL statement 
OPERATOR op! TRIGGERED BY SOME A,B 

establishes a data trigger on operator opl that allows it to execute only if there is 
new data on either data stream A or B. Again, the contents of data stream C are not 
considered in the trigger condition and have no effect on it. Conversely, if neither data 
stream A nor B has a fresh data value on it the tngger condition is not satisfied and 


the operator will not execute. 





Figure 14. PSDL Operator Model 


When a data trigger is satisfied, the operator will initiate execution by con- 
suming the values on all of its input data streams. An unsatisfied data trigger results 
in an operator not executing at all and its data streams are left intact. The data trig- 


ger iS an optional feature of the operator triggering condition. A null data trigger 
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effectively always evaluates to true and the operator is allowed to initiate execution 
regardless of the state of its data streams. Care should be taken in such cases not to 
consume a value from an empty data stream. Doing so results in a buffer error and 
the prototype’s execution will be interrupted. 

Assuming that an operator’s data trigger condition is satisfied, the opera- 
tor will consume its input data values and proceed to evaluate the input guard of the 
triggering condition. The input guard is a boolean expression dependent only upon the 
input values [Ref. 14]. Referring again to Figure 14, consider the PSDL statement 

OPERATOR op! TRIGGERED BY ALL A,B,C IF (A > B) AND(C > 0) 
The operator op] will first read all of its input data streams A, B, and C only if they all 
contain fresh data values. Assuming that the data trigger is satisfied, the operator 
must then evaluate the input guard, (A > B) AND (C > Q). If the values of A, B, and 
C satisfy this condition the operator is allowed to commit itself to complete execution 
and perform its function. If the input guard condition is not satisfied, the operator is 
not allowed to execute any farther and is terminated. The data streams will have 
been consumed and will not be restored to their original conditions prior to the trigger 
condition. The input guard is also optional. A null input guard effectively is always 
satisfied and the operator will be allowed to commit to complete execution. If both 
the data trigger and the input guard are null, the whole triggering condition is satis- 
fied by default and the operator is allowed to execute unconditionally. 

b. Exception Conditions 

The form of the EXCEPTION statement is shown in Figure 15. It consists 
of an exception identifier, an optional target data stream, and an optional exception 
condition. An EXCEPTION statement may specify only a single exception name but 
several EXCEPTION statements may be included in a set of control constraints. The 
target data stream is an output data stream that has been declared to contain a 
PSDL_EXCEPTION type. The exception condition is a boolean expression depen- 


dent on values of input data streams, calculated output data streams, and timers. 
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Exception_Statement = 


EXCEPTION Exception_Name ON Data_Stream IF Exception_Condition 





Figure 15. PSDL EXCEPTION Statement 


The example statement: 

EXCEPTION Out_of_Range ON Excp IF (A<0) AND (A>10) 
will raise a PSDL exception named Out_of_Range if the value of A is not in the 
range from zero to ten, inclusive. This example specifies a target data stream, named 
Excp, onto which the exception value is placed. This statement is used when the de- 
signer desires to explicitly transmit an exception to another operator which wul act as 
an exception handler. The data stream, Excp, must have been declared as an output 
data stream or as a local data stream and it must be of type PSDL_EXCEPTION. 
Had no exception condition been specified, the PSDL exception, Out_of Range, 
would have been raised unconditionally and output onto the target data stream, Excp. 

It was stated earlier that an atomic operator may also generate exceptions 
in the underlying language. The designer has the option of handling those exceptions 
in the underlying language or he may convert them to PSDL exceptions. When an ex- 
ception is produced in the underlying language (in this case, Ada) and is not handled 
in the atomic operator, an implicit control constraint is placed on the operator which 
forces the translator to build an exception closure which can trap the Ada exception 
and convert it into a PSDL exception. To do this, the des:;ner must declare the Ada 
exception names in the EXCEPTIONS statement in a PSDL operator specification. 
Figure 14 shows the form of an EXCEPTIONS statement. It is a sunple statement 
which lists one or more exception names which can be raised by an atomic operator. 
For example, a statement such as: 

EXCEPTIONS Out_of_Range, No_Data 
would declare two PSDL exceptions that could be raised by the atomic operator sub- 
components of the operator containing the statement. When an atomic operator rais- 


es any of those exceptions, they will be trapped by the translator’s code and a PSDL 
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exception with the same name will be transmitted on all output streams that are de- 


clared as PSDL_EXCEPTION streams. 


Exception_Declaration = 


EXCEPTIONS el, e2, ... ,eN 





Figure 16. PSDL Exception Declaration 


c. Tuner Conditions 
Timer conditions are control constraints that allow operators to manipulate 
any number of PSDL timers that are visible to them. The form of a timer condition 1s 
shown in Figure 17. It consists only of a PSDL timer function name followed by the 
target timer name and an optional! timer guard. For example, 
RESET TIMER tl IF tl > 45 sec 
is a timer condition which results in the timer named tl being reset when it reaches a 
value greater than 45 seconds. The timer guard in this example demonstrates a bool- 
ean operation on the value of a tumer. If the condition is not satisfied, 1.e., the value of 
tl is less than or equal to 45 seconds, the tumer operation is not executed. The timer, 
tl, must have been declared somewhere within the current operator’s preceding hier- 
archical structure. Recall that timers are visible in the operator in which they are de- 
clared and all of that operator’s subsequent descendants. 
The tuner guard is optional and a null timer guard is effectively equivalent 
to a true condition and the timer operation is unconditionally executed. Tumer guards 
are boolean expressions which can be dependent on values of operator input data, 


output data, and visible timers. 


Timer_Condition = 
Timer_Op TIMER Timer_Name IF Timer_Condition 


Timer_Op = 
RESET | START | STOP | READ 





Figure 17. PSDL Timer Condition Statement 
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d. Operator Output Conditions 
An output condition takes the form shown in Figure 18 and consists of the 
PSDL keyword, OUTPUT, followed by an output data stream name, followed by an 
output guard. The output data stream name must be one of the data streams declared 
in the OUTPUT statement in the operator specification or it may be a local data 
stream declared in a DATA STREAM statement. Unlike timer guards, output guards 
are not optional. The output guard is a boolean expression which depends on the val- 


ues of input data, output data, and timer values [Ref. 14]. 


Output_Condition = 
OUTPUT Data_Stream IF Output_Guard 


Figure 18. PSDL Output Condition Statement 


An output condition may be specified for any output data stream, but is not 
required. PSDL does not allow an operator to have more than one output condition 
per output data stream and it is illegal to have an output condition for an input data 
stream. If an output data stream does not have an output condition specified for it, a 
value will always be output to that stream unconditionally during operator execution. 

Normally, output conditions are used when it ts desired to restrict the data 
that is placed onto an output stream. To demonstrate the use of output conditions, 
consider the statement 

OUTPUT DIF (D> 0) AND (A = B) 
as applied to the operator in Figure 14. An output condition is established on opera- 
tor opl’s only output data stream, D. After the operator has executed its atomic 
module and calculated the value of D, it may wnite that value to its output data stream 
only if the output guard condition is satisfied, i.e., (D > 0) and (A = B). If this condi- 
tion is not met, the operator will not write the value of D onto its data stream, other- 
wise it will. Had no output condition been specified for D, the operator would have 


written the calculated value of D onto its data stream unconditionally. 
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IV. IMPLEMENTATION OF PSDL CONSTRUCTS 


A. TRANSLATOR INTERFACES 
The translator is only a single component in the whole CAPS system which must 
be interfaced with other components of CAPS. Specifically, the translator must inter- 
face with the static scheduler, the dynamic scheduler, and the user interface system. 
This section describes the implicit and explicit interfaces with these components. 
1. Translator/Static Scheduler Interface 
The interface with the static scheduler is completely implicit. The static sched- 
uler does not accept input from the translator and produce output based on it; instead, 
the static scheduler makes some assumptions about the structure and contents of the 
translator's output. The translator produces a set of Ada procedures which represent 
each unique atomic operator in a PSDL program. The static scheduler reads the same 
PSDL program and produces a set of procedure calls into the translator’s output 
which will invoke the atomic procedures in an order sufficient to meet the data flow 
and timing requirements of the PSDL prototype. To make this relationship work three 
assumptions were agreed upon by the static scheduler designer and the translator 


designer: 


- Atomic operator procedures adhere to a standard naming convention. 
- Atomic operator procedure calls are parameterless. 
- The translator output will have a standard name. 


a. Atomic Operator Procedure Naming 
When the translator produces Ada code for each atomic operator, it actual- 
ly produces a harness of Ada code into which the actual atomic operator’s code is 
placed. The harness consists of all the Ada code required to implement the control 
constraints on the atomic operators. The single-shot rule [Ref. 6:p. 25] states that 
no operator may be fired more than once inside any one parent composite operator; 
therefore it can be assured that all of the atomic operators in a single composite 


operator will be uniquely named. It is possible, however, that the same atomic 
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operator name may be used in other composite operators in a PSDL program. The set 
of control constraints may vary for each occurrence of that atomic operator. The trans- 
lator would then produce several different procedures because, although the atomic 
code in each procedure is identical, the control constraints may vary and the surround- 
ing harness code will be different in each instance. The problem to be solved in this 
case is how to make each of the atomic operators unique even when they use the 
same atomic name. 

To ensure that an atomic operator procedure would be uniquely named 
even if the actual atomic code inside it has been duplicated elsewhere in the PSDL 
program, a standard naming convention was agreed upon. This standard specifies 
that an atomic operator name will be represented by the concatenation of its parent 
operator’s name, followed by an underscore, followed by the atomic operator’s name. 
An advantage of the naming schema chosen is that the names are meaningful to the 
user and can be used as is for debugging purposes. 

An alternative solution to this problem is to build a tool which scans a 
PSDL program created in the user interface and physically maps each operator name 
to a unique name. The translator and static scheduler could then be guaranteed that 
no name in the entire PSDL input program would be duplicated. There would no long- 
er be any need for a naming convention since all atomic operator names would be 
unique to begin with. Such a tool could easily be constructed using Kodiyak. 

b. Procedure Parameter Passing 

The second concern about the translator’s output was whether or not the 
static scheduler should include parameters inside its atomic operator procedure calls. 
The translator was designed to account for parameters in atomic procedures so that 
the static scheduler could invoke these procedures without regard for their parame- 
ters. The static scheduler only needs to know the name of the atomic operator proce- 
dure and can invoke it with a parameterless procedure call. 

Recall that the translator actually produces a harness for the atomic opera- 
tor’s Ada code. The translator can recognize an atomic operator’s requirements for 
input and output parameters via the input and output data stream declarations in the 


atomic operator’s PSDL specification. All this infonnation is embedded into the 
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harness code as local information so the harness procedure itself requires no parame- 
ters. Thus when the static scheduler produces a call to an atomic operator using the 
naming convention described earlier, it is actually calling the harness procedure which 
in tum can call the actual atomic procedure and implement ail control constraints asso- 
ciated with that operator. 
c. Package Naming 

After the translator has produced all of the atomic operator procedures re- 
quired, it must package them in a manner that makes those procedure names visible 
to the static schedule. This is easily accomplished by placing the translator’s output 
in an Ada package body. Ada requires that a package body be accompanied by a 
package specification as well. The translator uses the package specification to make 
the procedure names visible to the static schedule. The data stream exceptions 
BUFFER_OVERFLOW and BUFFER_UNDERFLOW are also made visible in the 
package specification by renaming the same exceptions from the PSDL_SYSTEM 
package. 

The translator’s output package is called TL and 1s placed into a file called 
TL.a. The .a extension is required by the Ada compiler used in the development of 
this system. The Ada code produced by the static scheduler must utilize the Ada 
with clause to gain visibility to the TL package and all of its procedures as shown in 


Riguicae 


with TL; 
package STATIC_SCHEDULE ts 


end STATIC_SCHEDULE; 


package body STATIC_SCHEDULE is 


end STATIC_SCHEDULE; 





Figure 19. Use of Ada With Clause 
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2. Translator/Dynamic Scheduler Interface 

The interface between the translator and the dynamic scheduler is also an um- 
plicit interface. The issue of concern in this case is a matter of timing. The dynamic 
scheduler calls the time critical atomic operator procedures in the order specified by 
the static schedule. When a time critical operator finishes execution before the end of 
its period the dynamic scheduler will invoke a non-tune critical operator during the 
time remaining to the end of that period. Just before the end of the period, the non- 
time critical operator is interrupted, if it is still executing, so the next time critical 
operator can be invoked. To achieve this method of control, Ada tasks are used to un- 
plement the time critical and the non-time critical operators’ schedules. The Ada 
priority pragma is used to establish relative priorities among these tasks such that 
the time critical operators have the higher priority. [Ref. 15] 

Recall that a data stream is a mechanism which allows two or more operators 
to communicate via a single data value. The data stream is therefore a critical section 
which can be accessed by several operators. Any time an operator is performing a da- 
ta stream read or write operation it is inside a critical section and must not be inter- 
rupted. To ensure that a non-tume critical operator is not interrupted during a data 
Stream: operation, all data stream tasks are assigned a higher priority than the time 
critical operators. The actual interface between the translator and the dynamic sched- 
uler is simply an agreement of the task priority values. The non-time critical opera- 
tors are assigned a task priority value of one, the time critical operators are assigned 
a task priority value of three, and data stream tasks have a pniority value of five. 

It should be noted that although the priority pragma is a standard feature of 
any validated Ada compiler, the values that may be assigned in the pragina are unple- 
mentation defined and could very possibly range from zero to zero. Thus, using this 
pragma to assign varying priority values makes the execution support system imple- 
mentation dependent. 

3. Translator/User-Interface Interface 

The interface in this case is a combination of solid interface specifications and 

assuinptions. The user-interface is described in detail in [Ref. 16]. There are six is- 


sues to be dealt with in the translator’s interface with the user-interface: 
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- Syntactically correct PSDL source code. 

- No duplicated composite operator names. 

- Command line invocation of the translator. 

- Atomic Ada code is inserted into the PSDL source code. 

- User-defined types are placed at beginning of PSDL text. 

- The first PSDL operator after the user-defined types is the root operator. 


a. Syntactically Correct PSDL Source Code 

The translator depends on the user-interface for its input PSDL source 
code. The user-interface produces the PSDL source code via the syntax-directed edi- 
tor and the graphical editor. The first interface issue is an assumption that the PSDL 
source code produced in the user-interface is syntactically correct. The translator ap- 
plication generated by Kodiyak includes its own PSDL lexical analyzer and parser. If 
the input PSDL source code is not syntactically correct, the translator will terminate 
abnormally and ungracefully. Since this termination is built into the code produced by 
Kodiyak it cannot be controlled. 

b. Duplicated Composite Operators 

This issue is related to the standard naming convention used in the trans- 
lator/static scheduler interface. In fact, that naming convention is dependent upon this 
interface issue. The single-shot rule [Ref. 6:p. 25] prevents the duplication of any op- 
erator name, composite or atomic, in a single set of child operators. That is, given any 
PSDL operator it is guaranteed that that operator name will not duplicate any of its 
sibling operator names and that its children, if any, will all have unique names. 

This does not guarantee that operator name duplication will not occur 
among different branches of the PSDL hierarchical decomposition tree. Figure 20 
shows an example in which a composite operator is used twice during execution of 
the prototype. The single-shot rule is maintained throughout the decomposition. Ac- 
cording to standard hierarchical scoping rules, a name can be duplicated in two differ- 
ent scopes and represent two different objects. If that is the case in this example, 
and the operator D represents one operator in B’s decomposition while D represents 
a different operator in C’s decomposition, the translator will fail. The translator will 


assume that both instances of operator D are instances of the same operator and it 
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will only produce one set of atomic operator procedures to avoid a name conflict. 
Thus, if D was intended to name two different operators in different scopes, only one 
of those operators would have been produced and the Ada code generated by the 
translator would be semantically incorrect. This condition cannot be allowed to occur 
SO an assumption is made that there are no duplicated composite operator names in a 
PSDL source code input to the translator. This possibility for failure can be eliminat- 
ed by using the same naming conventions for composite operators as for atomic 


operators. 





Figure 20. Duplicated Composite Operators 


c. Invocation of the Translator 

The translator 1s an executable block of code that is activated by a UNIX 
command line entry. There are two interface issues involved here, the name of the 
translator command and the set of command line options available. The translator’s 
name is simply translator. To invoke the translator at the UNLX prompt type 

translator [options] filename -o TL.a 

where options are any of the set of legal command line options shown in Table | [Ref. 
ll:p. 206]. Filename is the name of the PSDL input source file, and -o sends the out- 


put of the translator to the file named TL.a. Normally, none of the command line 
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options should be selected except the -o option. See [Ref. 11] for a more detatled dis- 


cussion of Kodiyak translator options. 


TABLE1. TRANSLATOR COMMAND LINE OPTIONS 


Print out a list of legal options. 


Read input from file rather than the standard input. 


Continue attribute evaluation even after an error occurs. 

Print out tokens as they are scanned. 

Print out all grammar rule reductions as they occur. 

Turn on LEX’s debugging features. 

Tum on YACC’s debugging features. 

Generate a core image when a run-time error occurs. 

Print out storage statistics after all attribute evaluation is complete. 


-o file Divert the standard output to file. 





d. Insertion of Atomic Ada Code Into PSDL Code 

Originally, no provision was made for importing the actual reusable Ada 
code required to implement an atomic operator. The PSDL source code specified only 
the Ada procedure name in the software database. For example, 

IMPLEMENTATION Ada filename 

specifies that the atomic operator, filename, is stored in the software database and is 
to be used to implement this operator. The method of getting the reusable module 
from the software base and into the translator was not clearly defined. 

It was agreed that the IMPLEMENTATION statement in an atomic oper- 
ator’s unplementation would be exploited to make the actual Ada code visible to the 
translator. When the reusable module is retrieved from the software base it is insert- 
ed into the PSDL source code at the IMPLEMENTATION statement. It can easily 
be inserted by the retrieval system and then it can easily be extracted by the transla- 
tor and placed in the TL.a package produced by the translator. 
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The PSDL grammar required a slight modification to the IMPLEMENTA- 
TION statement to implement this feature. It 1s now 
IMPLEMENTATION Ada filename { source } 
where source refers to the actual Ada code retrieved from the software database. 
The source code must be bracketed by curly braces so the translator recognizes it as 
a comment and not as additional PSDL code. 
e. User-Defined Types 
Currently, user-defined types in PSDL have not been implemented. In an- 
ticipation of their implementation, it was decided that the layout of an input PSDL 
program would list all of the user-defined types at the top of the input file. This is so 
that during translation, a symbol table can be built for the user-defined types prior to 
their use in the PSDL program. In addition, a user-defined type must be located prior 
to any instance of its use in any other user-defined type. This follows very closely to 
the style of other conventional block structured languages like Pascal or Ada. 
f. Root Operator 
Recall that a PSDL program 1s a decomposition of a single operator into its 
components. The highest level composite operator in a PSDL program is called the 
root operator and it represents the system being prototyped. The operators in a 
PSDL program are listed after all of the user-defined types and the translator is de- 
pendent upon the order of appearances of the operators. The root operator must ap- 
pear before all other operators in the input file. After the root operator appears the 
only constraint on operator order is that any composite operator must appear before 
any of its subcomponent operators. 
4. Translator/Software Base Interface 
The translator implicitly interfaces with software base in that it expects the re- 
usable software components to be Ada procedures. Any other type of Ada construct 
will cause the translator to fail. This is an implementation restriction and it is antici- 
pated that future versions of the translator will allow various Ada constructs to be 


used as reusable components. 
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B. ADA IMPLEMENTATIONS OF PSDL CONSTRUCTS 
The following sections describe the actual Ada packages and procedures used to 
implement each of the major PSDL constructs described in Chapter OI. The data 
stream, exception, and timer constructs are pre-defined Ada packages and are resi- 
dent in an Ada package called PSDL_SYSTEM. This package contains all of the 
built-in type declarations in PSDL as well as the buffer errors that can be generated. 
Operator constructs are not resident anywhere because they are the results of 
translation. The aim of the translator is to produce the Ada code which realizes 
PSDL operators. Appendix A contains the Ada source code for each of the implemen- 
tations performed in this thesis. 
1. Data Stream Implementation 
Data streams are implemented as an Ada generic package containing an em- 
bedded task. Data streams are critical sections because they are referenced by sev- 
eral operators simultaneously, thus an Ada task 1s required for their mplementation. 
Ada makes no provision for generic tasks so to get around that constraint, tasks are 
embedded inside of generic packages. Inside the task are the various operations that 
must be allowed on data streams to implement things like data triggers and data 
Streain reads and writes. 
Four separate packages were constructed to implement the four variations of 


data streams. They include: 


- FIFO.a which implements a standard data flow stream. 

- SAMPLED.a which unplements a standard sampled data stream. 

- FIFO_STATE_VAR.a which implements a data flow state variable data stream. 

- SAMPLED_STATE_VAR.a_ which implements a sampled state variable data 
Stream. 


All of these data stream implementations use the same data structure shown 
in Figure 21 to represent the data stream. It is a simple Ada record structure con- 
sisting of two boolean flags to indicate , first, if the data stream is initialized, and sec- 


ond, if the data on the stream is a new value. The last field in the data stream record 
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is used to hold the value which resides on the data stream. This field takes the type 
established in the generic instantiated of the data stream package. 
a. Sampled Data Streams 

The GET operation first checks the data stream’s initialized flag and if it is 
set it will copy the value of the data stream into the formal parameter. If the 
initialized flag is not set, then the data stream has not yet executed a write (or PUT) 
operation and a BUFFER_UNDERFLOW exception is raised. Anytime the GET op- 
eration successfully reads a data value, the new_data flag will be cleared. 

The PUT operation is always successful in a sampled data stream. It will 
copy the value of the formal parameter into the data stream. The initialized flag and 


the new_data flag are always set after a PUT operation. 


type DATA_STREAM is 
record | 
INITIALIZED, 


NEW_DATA ~— : BOOLEAN; 
VALUE : ELEMENT_TYPE;  -- Generic input type 
end record; 





Figure 21. Data Stream Record Structure 


The CHECK operation sunply looks at the new_data flag and returns its 
value. It indicates whether or not the data stream has a new data value on it. 
CHECK is accessed by a function named FRESH. Ada wi: not allow functions inside 
of tasks, thus the FRESH function exists outside of the embedded task and invokes 
the CHECK procedure inside the task. FRESH retums true only if there is fresh data 
on the data stream. 

b. Data Flow Data Streams 

The GET operation is identical to the sampled data stream GET operation 
described above except that it will raise BUFFER_UNDERFLOW if the new_data 
flag is clear, that 1s, the buffer does not contain new data. 

The PUT operation first checks the new_data flag and, if it is set, will raise 
the BUFFER_OVERFLOW exception. If the mew_data flag is clear then the input 
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formal parameter value will be copied into the data stream and the new_data flag 
set. 

The CHECK operation simply returns the value of the new_data flag. The 
presence of data on the data flow stream is determined by the value of the new_data 
flag. If it is true, then there exists a data value on the data stream; if it is false, then 
no data value effectively exists on the data stream. The FRESH function is imple- 
mented here in the same manner as it is in the sampled data stream implementation. 
It is the FRESH function which actually accesses the CHECK operation. 

c. State Variable Data Streams 

State variable data streams are almost identical to their standard data 
stream counterparts. A state variable data stream must be instantiated with an ini- 
tial value and because of this, its mitialized and new data flags will be initialized to 
true. Other than this exception, a sampled state variable and a data flow state 
variable data stream are identical to a standard sampled and data flow data stream, 
respectively. 

An alternative method of implementing the state variable data stream is to 
use the normal data streams with no changes. The initial value of the state variable 
could be placed in the data stream by a PUT operation prior to the execution of the 
prototype. This method was not used in this thesis because it would require slightly 
more evaluation to be perfonned by the Kodiyak when building the translator. 

2. PSDL Exception Implementation 

The Ada enumerated data type was selected to represent the 
PSDL_EXCEPTION data type. The PSDL_EXCEPTION type actually does not 
exist until compile (or translation) tume. The translator is designed to scan the entire 
PSDL input program and collect all of the declared PSDL exceptions. Once the excep- 
tion names are collected, the translator constructs a type declaration for the 
PSDL_EXCEPTION type. The type declaration looks like 

type PSDL_EXCEPTION is (namel, name?2, ... nameN); 

where name] ... nameN are the unique exception names used in the input PSDL pro- 
gram. The PSDL_EXCEPTION type is declared so that it is visible to all of the oper- 


ator procedures constructed by the translator. 
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The implementation of a data stream to be used as an exception data stream 
is not constructed in this thesis. A firm definition of PSDL exceptions and their se- 
mantics has not been reached. The ideas presented in this thesis concerning PSDL 
exceptions are still only concepts which have not been realized. 

To implement exception data streams, a package similar to the FIFO.a imple- 
mentation is required. The new_data flag can be used to indicate if an exception is 
raised or not. A set flag implies a raised exception; a cleared flag implies a cleared 
exception. The PUT and GET operations should also be modified so they do not gen- 
erate any buffer errors. 

An exception cannot overwrite another exception value that is currently active, 
or raised. When the PUT operation is invoked on an exception data stream that is 
carrying an active exception, it should discard the new exception value and return nor- 
mally. The concept being enforced here is that the first exception generated has 
highest priority on a data stream until it is cleared. A data stream exception is 
cleared when the GET operation is performed. 

The FRESH function should be replaced with a function called ACTIVE. The 
ACTIVE function takes a single argument, a PSDL_EXCEPTION type, and returns 
true if the argument is currently in the data stream and has not been read. 

3. PSDL Timer Implementation 

Timers are umplemented as a generic package containing the tumer data struc- 

ture and the operations necessary for the timer state machine described in Chapter 


Ii]. The timer data structure is shown in Figure 22 and contains four fields: 


- START_TIME. Time when the last start operation was initiated. 

- STOP_TIME. Time when the timer was last stopped. 

- ELAPSED_TIME. Elapsed time accumulated up to the last stop operation. 

- PRESENT_STATE. The present state (running, stopped, or initial) of the timer 
State machine. 


The timer package uses the Ada CALENDAR package to gain access to the 
system clock and built-in time manipulation arithmetic such as subtracting the start 


tume from the system clock’s current time to get an elapsed time. The timer package 
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expects all time values to be in milliseconds since that is the default in PSDL. The 
translator automatically converts all tume expressions in the PSDL source code to mil- 


lisecond expressions. 


type STATE is (INITIAL, RUNNING, STOPPED); 


type TIMER Is 
record 
START_TIME, 
STOP_TIME : CALENDAR.TIME; 
ELAPSED _ TIME ~— : DURATION; 
PRESENT_STATE : STATE :=INITIAL; 
end record; 





Figure 22. PSDL Timer Data Structure 


4. PSDL Operator Implementation 

Unlike the other major PSDL constructs, PSDL operators do not have a stan- 
dard generic package ready to be instantiated. The implementation of operators is 
not a straight-forward process that can be performed by a single piece of Ada source 
code. An operator is a set of PSDL constructs and a set of PSDL control constraints 
that dictate how to manipulate the PSDL constructs in the current operator, as well 
as those constructs in any higher-level operators that are visible, like tuners. The 
implementation of the PSDL operator is the translator’s single most important 
function. 

The design of a PSDL operator implementation was driven by the semantics of 
PSDL and by the needs of the static scheduler. The PSDL semantics determined the 
use of Ada control structures to implement PSDL control constraints. The static 
scheduler drove the choice of structure for an Ada implementation of a PSDL opera- 
tor. The static scheduler requires a set of simple procedures which can be called in a 
specific order to effectively execute the prototype. An added requirement of the static 
scheduler is that the procedures must also be executed according to a set of timing 


constraints. The static scheduler must have total control over the execution of an 


atomic operator. Allowing the static scheduler to call a composite operator procedure 
which then calls its own subcomponent procedures implies that necessary timing con- 
Straints and operator precedence constraints would be determined and implemented 
by the translator itself. It would have to ensure that such constraints were buut-in to 
the translation. 

Doing this obviously defeats the purpose of the static scheduler and places an 
unnecessary requirement on the translator. Therefore, the static scheduler must de- 
termine all timing and precedence constraints and apply them to only the atomic oper- 
ators in a PSDL program. Only by scheduling the atomic operators can the static 
scheduler be guaranteed full control over tuning constraints. The requirement placed 
on the translator, then, is to produce a set of stand-alone procedures that the static 
scheduler can schedule individually and have confidence that only a single atomic op- 
erator will be executed at a time. 

Meeting that single requirement is a key issue in this thesis. Doing so means 
that a PSDL specification which is hierarchically structured must be broken down into 
a set of stand-alone procedures having a flat structure. The problem with a flat struc- 
ture is that nonnal visibility and scoping rules associated with a hierarchical structure 
no longer exist, yet there are rigid visibility rules that must be maintained in a PSDL 
operator. To meet this requirement, it was decided that a composite operator would 
be translated into a specification package containing all local PSDL construct instanti- 
ations and lines of visibility to all parent operator constructs. The lines of visibility 
are accomplished through the use of the Ada with and renames constructs. 

This method is best explained by example. Appendix B is a sample PSDL 
system which performs no particular function. The example consists of an enhanced 
data flow diagram, the corresponding PSDL source code, and Ada translation. For 
brevity, only the shaded portions of the enhanced data flow diagram will be dis- 
cussed. Operators C1, C2, and C3 are composite operators while Al, A2, A3, and A4 
are atomic operators. Operators C2 and C3 are subcomponents of Cl; operators Al 
and A2 are subcomponents of C2; and operators A3 and A4 are subcomponents of 
C3. Beginning at the root, the data streams visible in operator Cl are its local data 


streains a, b, c, and d. PSDL rules of visibility say that all of the data streams visible 
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in Cl are also visible in its subcomponents, C2 and C3. Examination of the PSDL 
specification of operator C2 reveals that C2 requires visibility of data streams a, b, c, 
and d in its parent, and a local data stream, e. Likewise, operator C3 requires 
visibility to data streams a, b, c, d, and its own local data stream f. The atomic opera- 
tor Al requires visibility to data streams a and e; atomic operator A3 requires visibili- 
ty to data streams c and f. 

During translation, a specification package would be generated for each of the 
composite operators and in this example they would all contain nothing but data 
stream package instantiations because data streams are the only type of PSDL con- 
structs used in this example. The specification packages for operators C1, C2, and C3 
are shown in section C of Appendix B. All the static scheduler is concemed with at 
this time is the set of procedure drivers used to implement only the atomic proce- 
dures. In this example procedures C2_Al and C3_A3 are two of those procedures. 
(The names used in this example are the actual names produced by the translator. 
Naming conventions are described in Chapter IV, section A.) 

Procedure C2 Al would be activated when the static scheduler wants to in- 
voke atonuc operator Al. Recall that operator Al must have access to data stream e 
in its parent operator C2, and it must access data stream a in operator Cl. To do this 
procedure C2_A1 must use the Ada with clause, 

with C2_SPEC; 
to gain visibility to everything that operator C2 can access. Notice that package 
C2_SPEC also uses a with clause, 

with Cl_SPEC; 
so that it may gain access to all of its parent operator’s data streams. Using the Ada 
with clause in this manner is the first step taken to establish a line of visibility from 
an atomic operator to its desired PSDL constructs. 

The second step is in the use of the Ada renames clause. Looking at proce- 
dure C2_ Al, the statement 

DSa.GET(TL_a); 
is a data stream procedure call. It specifies that the value of variable TL_a is to be 


written onto data stream DSa. DSa is a package and GET(TL_a) refers to a 
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procedure call within that package. But, which package does DSa really refer to? Be- 
cause there is no DSa package declared inside procedure C2_A1, Ada will attempt to 
look elsewhere for the package. The only place to look is in the C2_SPEC package 
because of the with clause associated with C2_Al. Inside package C2_SPEC, a 
package named DSa is indeed found, however, that DSa package is part of the 
renames clause, 
package DSa renames Cl_SPEC.DSa; 

That means any reference to the DSa package inside of package C2_SPEC is actually 
a reference to the DSa package inside C1_SPEC. Following that link up to C1l_SPEC, 
we see that the DSa package inside Cl_SPEC 1s the original data stream that was 
declared in composite operator Cl. Thus, the combination of Ada with and renames 
clauses has created a link, or line of visibility, from the actual data stream manipula- 
tion inside procedure C2_Al up to the ancestor operator where the data stream 
actually resides. The overall result is that procedures C2_Al and C3_A3 exist as 
stand-alone procedures in a flat structure that can be called in any order desired by 
the static scheduler. It can be guaranteed that each of those procedures has access 
to all of its required PSDL constructs no matter where those constructs exist in the 


hierarchical PSDL specification. 
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V. TRANSLATOR CONSTRUCTION 


A. MODIFYING PREVIOUS WORK 

After the implementations of data streams, timers, and exceptions were complet- 
ed, attention was turned toward producing an implementation of PSDL operators us- 
ing Kodiyak. This was the most significant task performed in this thesis. Previous 
work by Moffitt [Ref. 17] and Janson [Ref. 10] produced an incomplete Kodiyak pro- 
gram upon which this translator was based. Moffitt’s Kodiyak program was capable 
of parsing only PSDL programs with no boolean or arithmetic expressions. 

The PSDL grammar was designed without any syntactic rules for expressions. It 
was assumed that expression implementations would be dependent upon the underly- 
ing language used for the PSDL translation and therefore the syntactic rules for ex- 
pressions in the underlying language could be inserted in the PSDL grammar. 
Moffitt’s Kodiyak program implemented only the general PSDL grammar in Luqi’s 
dissertation with no capability for parsing expressions. 

Implementing the Kodiyak translator in this thesis began with modifying Luqi’s 
PSDL grammar so that it would include limited Ada expressions. Appendix C con- 
tains the updated PSDL grammar used in this thesis. Only boolean expressions 
were included in the updated version of PSDL because implementing the entire range 
of Ada expressions in the Kodiyak proved to be too time consuming. 

Once the grammar was completed, Moffitt’s Kodiyak was modified to accommo- 
date the new grammar. The process of modifying and installing the PSDL grammar 
was performed in conjunction with Marlowe and the static scheduler because the stat- 
ic scheduler uses Kodiyak as well to translate PSDL into a form consistent with its 
needs. At this point a version of Kodiyak existed which could successfully read and 
parse a PSDL program, however, it performed a null translation. By performing a null 
translation, the Kodiyak program was effectively a template whose attributes and at- 
tribute equations could be modified as needed to produce any desired translation of 
PSDL. 
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B. THE KODIYAK PROCESS 

Chapter II provided a brief overview of the Kodiyak translator generator and its 
purpose. Kodiyak is used in this thesis to convert a PSDL program into an abstract 
syntax tree (AST). Once in a tree structure the PSDL program can be scanned for in- 
formation about its hierarchical structure and its functionality. Two complete passes 
down and up the AST are required to produce an Ada translation of a PSDL program. 

Information about a PSDL program is stored in a Kodiyak map data type. The 
map type is the only high level data type offered in Kodiyak. The map type consists of 
a finite set of pairs which describe a function. A map pair consists of a key and an im- 
age such that the key is mapped into the image [Ref. 11:p. 12]. Maps are used in the 
translator to map a PSDL operator name into information about its structure, content, 
and context much like a symbol table is used in a compiler. Some of the items stored 


in maps include: 


- Whether an operator is composite or atomic. 
- The parent of an operator. 

- An operator’s input and output streams. 

- Data stream types. 


Figure 23 shows an example of an AST based on the PSDL grammar productions: 
Start -> psdl 
psdl -> component psdl | null 
component -> operator | data_type. 
This small subset of the PSDL grammar is suitable for providing a high level view of a 
psdl program structure in an abstract syntax tree. 

Movement through the AST is descnbed in terms of passes. A pass through the 
AST consists of either beginning at the root of the tree and proceeding down until all 
of the leaves have been visited, or beginning at the leaves of the tree and proceeding 
up to the root. In either case a pass is a one way trip through the tree. 
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Figure 23. PSDL Abstract Syntax Tree 


Pass one of the translator begins at the root of the AST, labelled START in Figure 
23, and proceeds down the tree in a depth-first order. The first PSDL module in the 
tree is a user-defined data type. Kodiyak will scan that module first, gathering infor- 
mation about the data type and storing that information in a map somewhere in the 
DATA_TYPE node. The second PSDL module in the tree is a PSDL operator. 
Kodiyak will scan this module just as it did for the user-defined type, storing all of the 
pertinent data about the operator in a map inside the OPERATOR node. The first 
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pass is complete when the last PSDL node has been scanned. Some of the useful in- 


formation collected at this point includes: 


- Every operator name and its parent. 

- Every data stream name, type, and classification as a sampled or data flow 
stream. 

- All exceptions declared in the program. 


However, all of this information is still segmented. The information in any single 
OPERATOR node is known only inside that node. To be useful for translation, all of 
the individual information maps distributed throughout the tree must be collected and 
their contents must be merged into a single map. 

Pass two begins at the bottom of the tree in the leaves and proceeds up. The very 
last PSDL node in Figure 23 is an empty node. It1is a result of the empty production 

psdl -> null 

and therefore contains no information. The information collection process actually be- 
gins with the next-to-last PSDL node since the last node is essentially empty. The 
information maps in each of the PSDL node’s children are merged into a single map in 
the PSDL node. The PSDL node then routes its combined information map up to its 
own parent PSDL node. In this manner all of the maps in each leaf node of the AST 
are bubbled up to the root of the AST. After the START node has collected all of the 
information from its children, it is left with a collection of data which represents the 
entire PSDL program in a single map. This map contains all of the contextual data 
about the PSDL program in the AST. 

Pass three begins at the root of the tree in the START node. Translation can begin 
now that contextual information is available for the entire tree. The presence of global 
context data is equivalent to possessing foreknowledge about the future of the PSDL 
program as well as remembering its past. The global map in the START node is rout- 
ed down the tree to each PSDL node. Translations are made at each node of the tree 
based on the data in the global map. 

These translations are strings of Ada code. As translations are made, they are 


Stored in a map in the leaves of the tree. At the end of pass three, the individual 
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translations of each PSDL node have been formed but they are still segmented just as 
the context data was at the end of pass one. 

Pass four begins at the leaves of the tree and proceeds up to the START node. 
Now the individual translations are gathered from each PSDL node and combined into 
composite groups of translated Ada code. Eventually, all of the translation informa- 
tion is combined in a single node at the root of the tree. 

The translation information can then be placed into slots of the TL package tem- 
plate, which is described later. The filling of the TL package template effectively pro- 
duces the TL package which is the final output from the translator. The TL package 
represents the Ada translation of the PSDL program in the AST. 


C. TRANSLATION OF PSDL EXPRESSIONS 

Before describing the overall translation process, attention should be devoted to 
the translation of PSDL expressions. PSDL expressions appear in a variety of PSDL 
Statements and the translation of those statements involves the translation of 
expressions. 

A PSDL expression is a simple boolean expression with two operands and a bool- 
ean operator. A PSDL condition is a complex PSDL expression, that is, any PSDL 
condition can be parsed into a group of one or more PSDL expressions joined by bool- 
ean operators. The translation of a PSDL condition involves the translation of each of 
its component expressions. 

The PSDL grammar (shown in Appendix C) has been modified from the original 
grammar in [Ref. 6] to handle boolean expressions. A PSDL condition is a boolean 
expression dependent upon values of data streams, timers and exceptions. PSDL ex- 


pressions are divided into three classes of expressions: 


- Timer expressions. 
- Exception expressions. 
- Normal expressions. 
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1. Timer Expressions 

Timer expressions are designed to allow two timers to be compared with each 
other or to allow a single timer to be compared with a constant time value. Figure 24 
shows the forms of timer expressions. PSDL timer visibility rules require that a timer 
name used in any timer expression must be visible in the current operator or a higher 
level ancestor operator. 

Timer constants represent a simple time value. They may be expressed as a 
positive integer followed by an optional time unit. Time units may be specified as mil- 


liseconds, seconds, minutes, or hours with milliseconds being the default units. 


Timer_Expression = 
timer_name rel_op ttmer_name 
| timer_name rel_op time_constant 


rel op = </<=/>1/>=/=I/= 
time_constant = integer unit 
unit = ms | sec | min | hours 





Figure 24. PSDL Timer Expression 


Timer expressions are translated to boolean expressions in Ada utilizing func- 
tion calls into the timer packages. The generic timer package is shown in Appendix 
A. For example, the expression 

Timerl < Timer2 
translates to the Ada expression 
. Timerl.READ < Timer2.READ 
where the READ function returns the present value of a timer in milliseconds. 
Timer expressions with constants are straight forward translations also. For 
example, the expression 
Timerl > 45 min 
translates to the Ada expression 
Timer].READ > 2700000. 
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The Kodiyak program itself recognizes time units and converts all time con- 
stants in a PSDL program to milliseconds. In the example above, 45 min is translated 
to an equivalent value of 2,700,000 milliseconds. 

When the PSDL grammar was modified to parse boolean expressions, it was 
patterned after the expression grammar of Ada. Therefore, PSDL follows the same 
precedence rules as Ada; the NOT operator has highest priority, followed by the 
AND and OR operations, followed by the relational operators. Parenthesized expres- 
sions will be given highest priority in any expression. 

When using timer expressions, there is a semantic subtlety which the design- 
er must be aware of. Timer expressions attempt to perform real-time operations, 
however, the computer system being used for development of this translator is a sin- 
gle-CPU machine. Expressions are evaluated left to right, sequentially. Consider the 
case when evaluating a timer expression like 

Timerl = Timer1. 
In real-time, the expression is always irue because a timer is always equal to itself. 
The Ada translation of this expression is 
Timerl.READ = Timer1.READ 
which is an expression of two calls to the READ function. The evaluation of this ex- 
pression is performed sequentially, left to nght. If the first function call occurs at time 
t, the second function call must occur at time t + d where d is at least the time re- 
quired to perform the first function call. If the value of d is significantly small, the dis- 
creetization error will compensate for the time difference and the two function calls 
will return the same value. On the other hand, if d is sufficiently large (greater than 
one half of one millisecond) the values returned by the function calls will be different 
and the expression will always be false! 

Ideally, either the Ada compiler or the translator should recognize this kind of 
Situation and optimize it. Presently, the translator makes no consideration at all for 
optimization. 

2. Exception Expressions 
An exception expression is of the form shown in Figure 25. The purpose of 


PSDL exception expressions is to check for the presence of a particular PSDL 
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exception on a data stream. Figure 26 shows an example of an exception expression 
and its Ada translation. The expression evaluates to true if a PSDL exception named 
exceptionX is currently active on the data stream named StreamX. StreamX must be 
an input data stream whose type is PSDL_EXCEPTION. 


Exception_Expression = 


Data_Stream_Name : Exception_Name 





Figure 25. PSDL Exception Expressions 


The expression is translated to a function call, ACTIVE, which returns a bool- 
ean value indicating if its PSDL exception argument is currently active. The ACTIVE 
function will clear the exception if it returns a true value, otherwise the exception val- 
ue currently on the data stream is left alone. The use of exception expressions any- 


where within an operator implicitly makes that operator an exception handler. 


PSDL: | 
StreamX : exceptionX 


Ada Translation: 
EXStreamxX.ACTIVE (psdl_exceptionX); 





Figure 26. PSDL Exception Expression Example 


3. Normal Expressions 

A normal expression is a PSDL expression involving only normal data 
Streams or constants. The form of a normal expression is shown in Figure 27 along 
with some examples of normal expressions. 

The stream names used in any PSDL expression must be visible to the atomic 
operator containing the expression. The translator presently has no means of per- 
forming its own visibility checking or type checking in a PSDL program. It is anticipat- 
ed that a static semantic analyzer for PSDL could be constructed to perform such 
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checks prior to sending a PSDL program to the translator. Such a tool could guarantee 


static correctness of the PSDL input to the translator. 


Normal_Expression = 
data_stream_name rel_op data_stream_name 
| data_stream_name rel_op constant 
| constant rel_op data_stream_name 


rel_op = <|<=/>|/>=l=I/= 





Figure 27. PSDL Normal Expression 


The translator can only handle scalar data types in normal PSDL expressions. 
This is a constraint imposed by the limited expression parsing capability given to the 
PSDL grammar in this thesis. The user must ensure that data streams and constants 
used in PSDL expressions are type compatible because their translations are subject 
to the strong typing of Ada. The addition of user-defined types in future versions of 
the translator will require modifications to PSDL’s expression handling capabilities. 

Currently, the Ada translations of normal expressions consist of Ada variables 
and constants. The translator will declare a variable for each data stream used in a 
normal expression. Variables are required because atomic PSDL operators consume 
their input data stream values once during execution, however, data stream values 
can be used any number of times in the same operator. The data stream value is 
stored in a variable so that it may be referenced as often as needed without having to 
read the data stream more than once. 

Figure 28 shows three examples of normal expressions that may be found in 
any PSDL condition. Translation A in Figure 28 shows the data stream variable dec- 
larations that would be generated to accommodate the expression translations shown 
in translation B. The variables are declared using the same type of their correspond- 
ing data streams. If Streaml were a data stream of type FLOAT, its associated vari- 
able, TL_Stream1, would be declared as a FLOAT variable. 
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Note the naming convention used to name data stream variables. It concate- 
nates the string "TL_" to the front of the data stream name. This is done to avoid 
naming conflicts. 

The three basic types of PSDL expressions described in this section are the 
building blocks of PSDL conditions. Since all three expression types produce boolean 
results, they can be used together in a single PSDL condition as in the statement 

OUTPUT a IF (a > 0) AND (t < 5 min) OR (excp : no_data) 


which uses an expression of all three types. 


PSDL: 
Streaml < Stream2 
Streaml > 10 
10 = Stream2 


Ada Translation:. © 
TL_Streaml1 < TL_Stream2 
TL_Streaml > 10 
10 = TL_Stream2 





Figure 28. Normal Expressions and Their Translations 


D. THE TL PACKAGE 

The final output of the translator is an Ada package named TL. A template de- 
scription of the TL package is shown in Figure 29. The TI package embodies all the 
Ada code necessary to simulate the atomic operators in a PSDL program. It is de- 
signed to provide visibility to all of the atomic operator drivers and to the Ada excep- 
tions which are to be handled by the dynamic scheduler/debugger. All other 
implementation specifics are hidden from the static and dynamic schedules. 

The Kodiyak translator generator [Ref. 11] was used to produce an executable 
program which translates an input PSDL file into the TL package. The source code 
used for the Kodiyak program is contained in Appendix D and is quite lengthy. It is 
not the intention of this thesis to describe the Kodiyak program line-by-line. Rather, 
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package TL Is 


type PSDL_EXCEPTION is (psdl_excp1, psdl_excp?2, ... , psdl_excpN); 
excpl, excp2, ...,excpN : exception; 


procedure atomic_driver1; 
procedure atomic_driver2; 


procedure atomic_driverJ; 





end TL; 
with PSDL_SYSTEM; 
use PSDL_SYSTEM; 


package body TL is 


atomic procedures drawn from software base 


PSDL operator specification packages 


PSDL atomic operator driver procedures 


end TL; 


Figure 29. TL Package Template 


the concepts of the translation process will be discussed by descnbing the formation 
of the TL package. 

The Kodiyak program itself was constructed incrementally by selecting a small 
section of the TL package and programming a Kodiyak program to produce the transla- 
tion for that section. Once the Kodiyak program could produce that section, a new sec- 
tion of the TL package was selected and the existing Kodiyak program was modified 
to produce the new section as well as the previous one. This incremental process 
continued until a final Kodiyak program existed which could produce the whole TL 
package. The TL package is divided into five major sections: 


- Exception declarations. 

- Atomic operator driver headers. 

- Atomic procedures. 

- PSDL operator specification packages. 

- PSDL atomic operator driver procedures. 


These five sections represent the portions of the TL package which are derived 
from the PSDL input program. The exception declarations section defines the 
PSDL_EXCEPTION data type and all of the PSDL exceptions that may be raised in 
the PSDL program. The atomic operator driver headers section lists the procedure 
names which are to be called by the static and dynamic schedules. This section is a 
requirement of Ada packages to ensure visibility into the actual atomic operator driv- 
ers in the package body. The atomic procedures section contains all of the Ada proce- 
dures drawn from the software base. The PSDL operator specification packages 
section contains all of the composite operator specifications. These specifications are 
represented as Ada packages containing only data stream and timer instantiations. 
The last section contains all of the procedures used to implement the atomic operator 
drivers. It is these procedures that are called by the static and dynamic schedules. 

1. PSDL Exception Declarations Section 

This section of the TL package declares the PSDL_EXCEPTION type and all 
of the PSDL exceptions that are found in the PSDL input program. The 
EXCEPTIONS statements in all of the PSDL specifications are used to generate the 
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translation to place in this section. An example of an EXCEPTIONS statement is 
shown in Figure 30 along with the translations that are derived from it. 

The EXCEPTIONS statement declares all the Ada exceptions that can be 
raised by an atomic operator. These exceptions must be captured by the ESS and 
converted to PSDL exceptions. 

Exception names in a single EXCEPTIONS statement may not be duplicated, 
however, an exception name may be included in any number of different 
EXCEPTIONS statements throughout a PSDL program. Recall that exception names 
are unique in PSDL, so that references to the same name in two or more 


EXCEPTIONS statements actually refer to the same PSDL exception. 


PSDL: 
EXCEPTIONS excpl, excp2, ... 


Ada Translation A: 


type PSDL_EXCEPTION is (psdl_excp1, psdl_excp2, ...); 
Ada Translation B: 
excpl, excp2,... : exception; 





Figure 30. EXCEPTIONS Statement Translation 


There are two parts to the translation of the EXCEPTIONS statement. The 
first part, translation A in Figure 30, places the exception names into a map. This map 
will be combined with the exception name maps of other atomic operators to generate 
a single list of PSDL exception names. To avoid naming conflicts, each exception 
name in the EXCEPTIONS statement is prepended with the string "psdl_" when 
placed into the map. At the end of pass four in the translator, the combined exception 
names are used to generate the PSDL_EXCEPTION type declaration as shown in 
Figure 30. This type is an Ada enumerated data type where the enumerated items 
are the unique exception names retrieved from the map. 

Translation B in Figure 30, generates the Ada exception declarations. These 
are the actual exceptions raised by the atomic components from the software base. 


The names in the EXCEPTIONS statement are not altered when translated into Ada 
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exception declarations. Like their PSDL counterparts, Ada exceptions used in a 
PSDL program are unique. Multiple references to the same exception name refer to 
the same exception regardless of location in the PSDL source code. 

2. Atomic Operator Driver Headers Section 

This section is a requirement of Ada, not of PSDL or CAPS. Visibility to the 
objects contained inside an Ada package body are determined by the package specifi- 
cation [Ref. 18:p. 7-1]. It is desired to provide visibility only to the exceptions which 
could be generated by a PSDL program and to the atomic operator drivers. The state- 
ments in this section are simply the procedure headers of the atomic operator drivers 
with no bodies. 

The atomic operator driver headers are produced during the third pass of the 
Kodiyak program. Figure 31 highlights the portions of the PSDL program which deter- 
mine these translations. When processing the PSDL statement, 

OPERATOR Sub_Operator_Name TRIGGER Triggering Condition, 

the contextual data from pass two is used to identify Sub_Operator_Name as an 
atomic operator or composite operator. If it is atomic, a procedure header will be gen- 
erated for it by concatenating the strings "procedure", Parent_Operator_Name, '_", 
Sub_Operator_Name, and ";”. Parent_Operator_Name is known from_ the 
OPERATOR statement in the PSDL specification section. The concatenated string is 
stored in a map. If there are any more atomic subcomponents in the current operator, 
their procedure headers will be stored in the map also. If Sub_Operator_Name is a 
composite operator, no procedure header will be generated because composite opera- 
tors are not executable and therefore do not require a driver. 

During pass four of the Kodiyak, all of the atomic operator driver headers are 
collected into a single string which is then placed into the atomic operator driver head- 
ers section of the TL package. 

3. Atomic Operators Section 

This section of the TL package contains a set of Ada procedures which are the 
reusable components drawn from the software base. The user interface inserts these 
procedures into a PSDL program before it is sent to the translator. Figure 32 high- 
lights the PSDL statement used to derive this section. 
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Translation of Atomic_Source is more of a cut and paste operation than a 
translation process since Atomic_Source is already in Ada code. During pass one, 
Source_Code is collected in its entirety and placed into a map. Pass two then collects 
all of the various Atomic_Sources in the PSDL program and combines them into a sin- 
gle map item. The translation is effectively complete at the end of pass two. 

The single map item representing all of the atomic procedures as a whole is 


placed into the atomic operators section of the TL package at completion of pass four. 


OPERATOR Parent_Operator_Name 


SPECIFICATION 

END 

IMPLEMENTATION GRAPH 
Link Statements 
DATA STREAM ... 
TIMER  ... 

CONTROL CONSTRAINTS 


OPERATOR Sub_Operator_Name 


TRIGGER Triggering Condition 
CONSTRAINTS 


END 





Figure 31. Statements Used to Build Atomic Procedure Header 


4. PSDL Operator Specification Packages Section 
This section contains a set of Ada package specifications. There is an Ada 
package specification for every composite operator in a PSDL program. Each specifi- 
cation package can be represented by a template with various slots. The specification 
package template in Appendix E was derived to guide the development of the Kodiy- 
ak program. It is a template of an Ada package specification with slots to fill in. 
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OPERATOR Atomic_Operator 
SPECIFICATION 





Figure 32. Statements Used to Build Atomic Operator Header 


The translator must map certain PSDL statements into the slots in the specifi- 
cation package template. The slots in the specification package template represent 
data stream and timer instantiations. Since these packages only serve to declare da- 
ta structures, no accompanying package bodies are required. The slots of the specifi- 


cation package template are: 


- Package header slot. 

- Input / output stream instantiations slot. 

- State variable data stream instantiations slot. 
- Local data stream instantiations slot. 

- Local timer instantiations slot. 


a. Package Header Slot 
This slot names the current operator’s package and its parent operator’s 


specification package. The Ada code which fills the slot is formed by translating the 
PSDL statements shown in Figure 33. 

There are two ways to translate a PSDL operator specification header into 
the specification package header. Translation A in Figure 33 shows the most 
common translation, it contains an Ada with clause. Parent_Operator_SPEC is the 
name of the specification package belonging to the parent of Current_Operator. By 
“withing” the parent specification package, the current operator is given a line of visi- 
bility into it so that the current operator may access any external PSDL constructs in 


its parent operator. 
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The name given to the specification package being formed is simply the 
name of the current composite operator, Current_Operator in this example, concate- 
nated with the string "_SPEC’. 

Translation B is a special case and only applies to the roct operator. The 
root operator has no parent, therefore there is no need to use a with clause. The only 
translation to perform is the package name which is identical to the procedure just de- 


scribed in Translation A. 


PSDL: 
OPERATOR Current_Operator 
SPECIFICATION 


Ada Translation A: 


with Parent_Operator_SPEC; 
package Current_Operator_SPEC is 
Ada Translation B: 


package Current_Operator_SPEC Is 





Figure 33. Operator Specification Header Translation 


b. Input/Output Stream Instantiations Slot 
This slot contains data stream package instantiations corresponding to the 


data streams listed in the INPUT and OUTPUT statements of a PSDL operator speci- 
fication. Figure 34 shows an example of each and their translations. 

The INPUT and OUTPUT statements describe the external inputs and 
outputs to and from an operator. To the translator, they indicate the particular data 
Streams visible in the parent operator which should also be visible inside 
Current_Operator. 

The names used in the INPUT and OUTPUT statements must replicate 
names used in the parent operator. For example, if a parent composite operator owns 
two data streams named X and Y, and an atomic child operator wants to use X as an 
input stream and Y as an output stream, then the atomic child must use the names X 


and Y in its INPUT and OUTPUT statements. If a data stream name is used in an 


INPUT or OUTPUT statement which is not used in the parent operator, then a se- 
mantic error results which will cause the translator to rename a package that does not 
exiSt. 

The translation of an INPUT or OUTPUT statement is simply a renaming 
of a data stream package which can be found in the parent operator’s specification 
package. All data stream packages are named by prepending the letters "DS" to the 
Stream names listed in the INPUT and OUTPUT statements. 

It was decided during the design of the translation, that an INPUT or 
OUTPUT statement used in the root operator would be semantically incorrect. The 
root operator represents the highest level operator in the system, in fact it is the sys- 
tem. As such, there are no external operators to communicate with the root, there- 


fore there should be no external inputs or outputs to or from the root. 


PSDL: 
INPUT Stream1, Stream2 : type_name 
OUTPUT Stream3, Stream4 : type_name 


Ada translation: 
package DSStream1 renames Parent_Operator_SPEC.DSStream]1; 
package DSStream2 renames Parent_Operator_SPEC.DSStream2; 
package DSStream3 renames Parent_Operator_SPEC.DSStream3; 
package DSStream4 renames Parent_Operator_SPEC.DSStream4; 





Figure 34. INPUT, OUTPUT Statement T:.-nslations 


c. State Variable Data Stream Instantiations Slot 
This slot contains the Ada code required to instantiate state variable data 


streams. The STATES statement in a PSDL operator specification is the source of 
translation. Figure 35 shows an example STATES statement and its translation. 

The STATES statement declares local internal state variables inside 
Current_Operator. To the translator, these are new state variable packages which 


must originate inside Current_Operator’s specification package. 
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The names used in the STATES statement must not duplicate any data 
stream names used in an INPUT, OUTPUT, or DATA STREAM statement. Such an 
occurrence would cause the translator to generate two data stream packages with the 
same name in the same specification package. The Ada compiler will not allow this. 

The items in initial_value_list must be scalar constants compatible with 
type_name. Arithmetic constant expressions are not allowed in this version of the 
translator because arithmetic expressions are not a part of the PSDL grammar. Fu- 
ture versions may implement this feature. The number of initial values in the initial 
value list must be at least one. The first initial value will be associated with the first 
State variable; the second initial value is associated with the second state variable, 
and so on. If there are more initial values than state variables, the extra initial values 
are ignored. If there are fewer initial values than state variables, the last initial value 
in the list is assigned to all state variables without a corresponding initial value. For 
example, the statement 

STATES A,B,C,D : INTEGER INITIALLY 0,1 
would assign a value of zero to state variable A and a value of one to state variables 
B, C, and D. 

State variables are translated into new instantiations of state variable da- 
ta streams with an initial value as shown in Figure 35. Because they are data 
streams, the standard data stream naming convention of prepending "DS" to the 
stream names in the STATES statement is used. Whether the state variable is in- 
Stantiated as a sampled or data flow data stream depends on the use of the data 
stream in lower level operators. Recall that only data streams used in a BY ALL 
trigger condition are data flow streams, all others are sampled streams. Since the 
classification of the data stream is dependent upon its context, this translation cannot 
be performed before pass three of the translator. 


d. Local Data Stream Instantiations Slot 
This slot contains the Ada code required to instantiate new data streams 


which are local to the current operator. These instantiations are translations of the 
DATA STREAM statement found in a PSDL operator implementation. Figure 36 
shows an example of a DATA STREAM statement and its translation. 
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PSDL: 
STATES StreamS5, Stream6 : type_name INITIALLY initial_value_list 


Ada translation: 
package DSStreamS is new SAMPLED_STATE_VAR (type_name, initial); 
package DSStream6 is new DATAFLOW_STATE_VAR (type_name, initial); 





Figure 35. STATES Statement Translation 


The purpose of the DATA STREAM statement is to declare local data 
streams in a composite operator which may be used by its subcomponent operators. 
The rules for input, output, and state variable data stream names apply to local data 
Streams as well. The names declared in a DATA STREAM statement cannot dupli- 
cate any other data stream names declared in a higher level operator, i.e., there can- 


not be two different data streams with the same name in a PSDL program. 


PSDL: 
DATA STREAM Stream], Stream2, .. : type_name 


Ada Translation: 


package DSStream]1 is new SAMPLED_STREAM(type_name); 
package DSStream2 is new DATAFLOW_STREAM(type_name); 





Figure 36. DATA STREAM Statement Translations 


A DATA STREAM statement is translated into a set of data stream pack- 
age instantiations. Because the data streams are local, they must be instantiated 
using the Ada new statement instead of the renames statement used for data 
streams in INPUT and OUTPUT statements. Whether to declare the data stream 
package as a sampled or dataflow stream is dependent upon the stream’s context. 
The context is not known until pass two of the translator and the translation is not 


performed unt pass three. 
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e. Local Timer Instantiations Slot 
This slot in the specification package template contains the Ada code re- 


quired to instantiate timer packages. Figure 37 shows an example of a TIMER state- 
ment and its translation. 

The Ada code in the timer instantiations slot comes directly from the trans- 
lation of the TIMER statement. The translation itself is performed during pass three 
of the translator, however, it could just as well have been performed in the first pass 
because there is no dependence at all upon the context of the timer. 

To avoid naming conflicts, the translator prepends the string “TM_" to all 
timer names as shown in Figure 37. 

After all of the slots in the specification package template have been filled 
with Ada code, they are concatenated together to form a single Kodiyak string which 
is the specification package. That string is placed into a map and will be collected and 
combined with all of the other specifications packages in the PSDL program. This fi- 
nal collective group is placed into the PSDL operator specification packages section of 


the TL package template. 


PSDL: 
PPIVIER Dietz see 


Ada Translation: 
package TM_t1 is new PSDL_TIMER; 
package TM_t2 is new PSDL_TIMER; 





Figure 37. TIMER Statement Translation 


5. PSDL Atomic Operator Driver Procedures Section 
This section of the TL package contains a set of Ada procedures which act as 
drivers for the procedures drawn from the software base. Each of the procedures in 
this section implements an atomic operator in terms of its PSDL control constraints. 
These procedures are constructed during passes two, three, and four of the Kodiyak 
program. A driver procedure must be built when the Kodiyak is processing a 
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composite PSDL operator which has atomic subcomponents. It is in this situation 
when the Kodiyak has access to the information required to build the driver proce- 


dure. That information includes: 


- The atomic operator name. 
- The parent operator name. 
- The atomic operator’s control constraints. 


The construction of a driver procedure can be patterned after the implementa- 
tion template shown in Appendix E. The implementation template is a partial Ada 
procedure with seven slots to be filled in. The translator must map certain PSDL 
Statements into each of these slots to perform a successful translation. The slots to 
be filled in are: 


- A header slot. 

- A data stream variable declaration slot. 
- A triggering condition slot. 

- An atomic procedure call slot. 

- A control constraints slot. 

- An unconditional output slot. 

- An exception closure slot. 


Following is a description of how various PSDL statements are interpreted and trans- 
lated into Ada code in the implementation template. 


a. Header Slot 
Slot one is the header slot. To fill this slot, the translator must generate 


an Ada with clause, and Ada use clause, and the procedure name. The with and use 
clauses import the parent operator’s specification package. This gives the atomic 
operator driver access to any data streams and timers that were visible in the parent 
operator. The procedure name of the atomic operator driver is constructed by concate- 
nating the parent operator name and the atomic operator name with an underscore 
character between them. 

The translation required to fill this slot is performed during pass three of 
the Kodiyak. The set of PSDL statements used for the translation are highlighted in 


Figure 31. The upper highlighted statement specifies the name of the parent operator; 
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the lower statement names the atomic subcomponent. If the subcomponent in the 
lower statement is a composite operator, no translation is performed for it. Compos- 
ite Operators are not executable, therefore they do not have an atomic procedure for 
which a driver must be constructed. The with and use statements in the header slot 
are formed by concatenating the parent operator name in the upper highlighted state- 
ment in the figure with the string, "_SPEC;”. Using the generalized PSDL operator in 
Figure 31, the translation of the highlighted statements appears as 

with Parent_Operator_SPEC; 

use Parent_Operator_SPEC; 


procedure Parent_Operator_Name_Sub_Operator_Name is 


end Parent_Operator_Name_Sub_Operator_Name; 


b. Data Stream Variables Slot 
Slot two is the data stream variables slot. This slot declares Ada vani- 


ables which will be used to physically interface an atomic operator with its data 
streams. The statements which contribute directly toward the translation of the data 
Stream variables are the INPUT and OUTPUT statements in an operator specifica- 
tion. The INPUT and OUTPUT statements determine the variables needed to make 
a procedure call to the atomic Ada code. 

Consider the INPUT and OUTPUT statements in Figure 38. If these state- 
ments belong to an atomic operator’s specification, then they can be interpreted as 
the input and output parameters to the atomic procedure. However a, b, c, x, y, and z 
are all data streams in the PSDL specification but the procedure must be called with 
actual parameters as in 

Atomic_Procedure_Call (TL_a, TL_b, TL_c, TL_x, TL_y, TL_z); 

When the translator scans an atomic operator’s INPUT and OUTPUT statements, the 
Stream names in those statements and their types are stored in a map during pass 
two. Later, when the atomic driver procedure is being formed, those stream names 
can be recalled from the map along with their types and translated into variable 
declarations as shown in Figure 38. To avoid name conflicts, variable names are 


formed by prepending the string "TL_" to the data stream name. 
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c. Triggering Condition Slot 
Slot three in the implementation template is to be filled with the triggering 


condition translation. Triggering conditions were described in Chapter HI. The form 
of an atomic operator’s triggering condition is shown again in Figure 39 along with the 
form of its translation. The translation of a triggering condition involves the transla- 
tion of its data trigger and input guard as shown in Figure 40. 

Triggering conditions are translated into Ada conditionals (If-Then state- 
ments) where the conditions to be evaluated are the Ada translations of the data trig- 
ger and input guard. The input guard is nothing more than a PSDL condition and is 
translated as described previously in section C. The data trigger checks for the pres- 
ence of new data values on its data stream arguments. The FRESH function of the 
data stream implementation is used to realize a data trigger, recall that the FRESH 
function returns true if there is a new data value on its data stream, otherwise it re- 
turns false. Figure 40 shows that a data trigger can be a BY ALL or a BY SOME 
trigger. The BY ALL trigger requires fresh data on all of its data stream arguments. 
This type of trigger is translated into a series of boolean function calls joined by the 
Ada AND operator. The BY. SOME trigger requires fresh data on at least one of its 
data stream arguments. It is translated into a series of boolean function calls joined 
by the Ada OR operator. 

Both the data trigger and the input guard may be null conditions. In each 
case a null condition is translated to a boolean constant value of true so the condition 
will always be satisfied during execution. 

Embedded within the translation of a triggering condition is a translation to 
read data stream values. This is a semantic requirement of PSDL; recall that if a data 
trigger 1s satisfied, a PSDL operator will consume its data stream input values. The 
PSDL statement required for this translation is the INPUT statement of the atomic 
operator's PSDL specification. Figure 41 shows an example of an INPUT statement 
and its corresponding translation into data stream read operations. The GET proce- 


dure of the data stream implementations are used to implement this requirement. 


ai 


PSDL: 
INPUT a,b,c : type_name 
OUTPUT x, y, z : type_name 


Ada Translation: 
TL_a : type_name; 
TL_b : type_name; 
TL_c : type_name; 
TL_x : type_name; 
TL_y : type_name; 
TL_z : type_name; 





Figure 38. Data Stream Variable Translations 


PSDL expressions are translated into Ada boolean expressions whose op- 
erands are data stream variables, timers, or exceptions. If any data stream vanables 
are used in a PSDL operator, the data stream read translation is necessary to ensure 
those variables have initial values. Only the input data stream variables need to be 
initialized, the output data stream variables are initialized by the atomic procedure 


when it 1s called by the atomic procedure driver. 


Tnggering Condition = 
TRIGGERED Data_Trigger IF Input_Guard 


Ada Translation: 
if Data_Tngger_Translation then 
Read Input Streams 
if Input_Guard_Translation then 


end if; 
end if; 





Figure 39. PSDL Triggering Condition Translation 


72 


Data_Trngger = 
BY ALL id], id2, ... 
| BY SOME 1d], id2, ... 
| = null 


Input_Guard = 
PSDL_Condition 
| = null; 


Ada Translation: (Data_Trigger) 
DSid1.FRESH and DSid2.FRESH 
DSid1.FRESH or DSid2.FRESH 


Ada Translation: (Input_Guard) 
refer to section C, Translation of PSDL Expressions 





Figure 40. PSDL Data Trigger and Input Guard Translation Forms 


d. Atomic Procedure Call Slot 
Slot four of the implementation template is filled with an Ada procedure 


call. The procedure being called belongs to the group of reusable components drawn 
from the software base. Each atomic procedure driver calls one of those atomic proce- 
dures. The translation of the atomic procedure call is generated from the INPUT and 
OUTPUT statements of the atomic operator’s PSDL specification. The data streams 
in these statements correspond to in and out parameters in an Ada procedure. The 
exception to this is for data streams of type PSDL_EXCE? TION. PSDL exceptions 
are not permitted to be used as parameters for an atomic procedure. Exceptions 
raised in atomic procedures are Ada exceptions which the translator is responsible for 
converting into PSDL exceptions and transmitting on PSDL_EXCEPTION data 
streams. 

When the translator scans the INPUT and OUTPUT statements of an 
atomic operator, the data stream names are collected into a map entry which is the 
parameter list to be used in the atomic procedure call. During pass three of the trans- 


lator, this map entry is retrieved and converted into a procedure call when an atomic 
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operator is being scanned. Figure 42 shows an example of the PSDL statements re- 
quired to produce an atomic procedure call. The name used for the atomic procedure 
call is the exact name given in the statement 


OPERATOR Atomic Name TRIGGERED .... 


PSDL: 
INPUT x, y, z : type_name 


Ada Translation: 
DSx.GET(TL_x); 
DSy.GET(TL_y); 
DSz.GET(TL_z); 





Figure 41. Data Stream Read Translation 


e. Control Constraints Slot 
Slot five of the implementation template is a collection of translations of 


timer operations, exception operations, and conditional output operations. Timer op- 
erations can be directly translated into Ada if-then statements. The three timer oper- 
ations and their translations are shown in Figure 43. The timer condition is a PSDL 
condition and is translated as described in section C. Timer operations are translated 
into procedure calls to timer packages. Examination of the PSDL grammar in Appen- 
dix C shows that the timer condition is optional. Ifa null timer condition is specified, 
the translator will interpret it as a boolean constant of value, true. The constant true 
value will force the Ada if-then translation of a timer operation to always execute. 
For example, the timer operation 
START TIMER t1 

will translate to the Ada if-then statement 

if true then 

tl. START; 
end if; 


which will always execute. 
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PSDL: 
OPERATOR Atomic_Name 
SPECIFICATION 
INPUT a, b,c : type_name 
OUTPUT x, y, z : type_name 


END 
IMPLEMENTATION ADA Atomic_name {Source_Code} 
END 


Ada Translation: 
Atomic_Name (TL_a, TL_b, TL_c, TL_x, TL_y, TL_z); 





Figure 42. Atomic Procedure Call Translation 


Exception operations are also direct translations. Figure 44 shows the 
forms of an Exception operation and its translation. Exception operations have only a 
single form, however the exception condition is optional. If an exception condition is 
specified, the EXCEPTION statement will be translated into an Ada if-then 
statement. The exception ‘condition is a PSDL condition and is translated as 
described in section C. The exception operation is translated into a data stream PUT 
procedure call. To be semantically correct, the data stream must have been declared 
as a PSDL_EXCEPTION, if not, then a type mismatch will occur during compilation of 
the Ada translation. 

The translator handles a null exception condition in the same way a null 
timer condition is handled. The condition_translation is a boolean constant of value, 
true. The Ada if-then statement representing the EXCEPTION statement will 
always execute if the exception condition is null. 

When the concept of PSDL exceptions was being designed, it was desired 
to have PSDL exceptions behave as closely as possible to Ada exceptions. The Ada 
return statement shown in the translation of a PSDL EXCEPTION statement is an 
attempt to meet this requirement. The overall function of the EXCEPTION statement 
is to place a PSDL exception onto a data stream and then terminate execution of the 


atomic operator. The return statement achieves this effect. 


fis 


PSDL: 
STOP TIMER t1 IF Condition] 
START TIMER tl IF Condition2 
RESET TIMER t1 IF Condition3 


Ada Translation: 
if Condition1_ Translation then 
tl .STOP; 
end if; 


if Condition2_ Translation then 
tl START; 
end if; 


if Condition3 Translation then 
tl.RESET; 
end if: 





Figure 43. PSDL Timer Operation Translations 


The final control constraint to be translated 1s the conditional output 
statement. The forms of the conditional output statement and its translation are 
shown in Figure 45. The translation of conditional output statement is very similar to 
the translations of the previous two types of control constraints. The main difference 
is that the output condition is not optional. 

Conditional output statements are translated into Ada if-then statements, 
also. A list of output data streams may be specified in the statement and the 
translator will generate a data stream PUT procedure call for each stream in the list. 
The semantic restrictions on the conditional output statement are that no data stream 
be listed in more than one output statement; and no PSDL_EXCEPTION data 
streams may be listed in the output statement. Output to a PSDL_EXCEPTION data 
stream is accomplished in the EXCEPTION statement previously described. 

Control constraints are translated in the order which they are written in the 
PSDL program. The PSDL grammar does not specify a standard ordering for control 
constraints so they may be placed in any order desired as long as they all follow the 
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operator TRIGGER statement. The designer should be aware of control constraint 
ordering when using the EXCEPTION control constraint because if the EXCEPTION 
Statement is executed, none of the following control constraints will be executed. All 
of the control constraint translations are combined into a single Kodiyak string and 
placed into a map in the atomic operator’s node in the abstract syntax tree. This map 


entry is then used to fill the control constraints slot in the implementation template. 


PSDL: 
EXCEPTION excp ON Data_Stream IF Condition 


Ada Translation: 


if Condition_Translation then 
DSData_Stream.PUT(psdl_excp); 
return; 

end if; 





Figure 44. PSDL EXCEPTION Statement Translation 


f. Unconditional Output Slot 
Slot six in the unplementation template 1s the unconditional output slot. 


The translator fills this slot with zero or more data stream PUT procedure calls. An 
implicit translation 1s made to fill the slot based on the conditional output control con- 
straints. An atomic PSDL operator must write calculated cata values to all of its out- 
put data streams sometime before it terminates. Output may be done conditionally 
using the conditional output statement described previously, or unconditionally. Any 
output data stream that is not written to in a conditional output statement must be 


written to in an unconditional output statement. 


ie 


PSDL: 
OUTPUT x, y IF Condition 


Ada Translation: 
if Condition_ Translation then 
DSx.PUT(TL_x); 
DSy.PUT(TL_y); 
end if; 





Figure 45. Conditional Output Statement Translation 


Figure 46 shows an atomic operator named AO with output data streams 
named x, y, and z. Assume that in AQO’s control constraints there is a single condi- 
tional output statement in which data stream x 1s the only stream specified. The 
translator will generate Ada code to unconditionally output to data streams y and z at 
the end of the control constraints translations. The translations appear as 

DSy.PUT(TL_y); 
DSz.PUT(TL_z); 
in the unconditional output slot in the implementation template. 


g. Exception Closure Slot 
Slot seven in the implementation template contains the exception closure 


used to capture Ada exceptions raised by the atomic operator procedure and convert 
them to PSDL_ exceptions. The exception closure 1s translated from _ the 
EXCEPTIONS statement in the PSDL operator specification. The purpose of the 
EXCEPTIONS statement is to list all of the Ada exceptions that may be raised in the 
atomic procedure. The translator must construct an exception closure which recogniz- 
es those Ada exceptions and converts them to PSDL exceptions. Figure 47 shows 
an example of the statements required to construct an exception closure. 

The translator requires information gathered from the EXCEPTIONS and 
OUTPUT statements in an atomic operator’s PSDL specification in order to construct 
the exception closure. When the translator scans any output data streams of type 
PSDL_EXCEPTION, it places their names into a map. When the EXCEPTIONS 
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statement is scanned, each exception name in the list is translated into an Ada excep- 
tion handler statement of the form 

when exception_name =>. 
The translator then produces the required data stream PUT procedure calls by 
recalling the names of the output PSDL_EXCEPTION data streams. The example 
translations shown in Figure 47 would be produced for an atomic operator with output 


data streams named x and y, and exceptions named excp1 and excp2. 


OPERATOR AO 


OUTPUT x,y,z : INTEGER 


END 


Elsewhere in AO’s control constraints: 
OUTPUT x IFx>0 





Figure 46. Unconditional Output Example 


An exception closure translation is always produced for every atomic oper- 
ator regardless of the presence of an EXCEPTIONS statement. If there is no 
EXCEPTIONS statement in an atomic operator, an empty exception closure is pro- 
duced. An empty closure simply re-raises any Ada excepiions that might be raised 
by the atomic procedure. The empty closure appears as 

exception 
when others => 
raise; 
which will trap any Ada exception and raise it again to be handled elsewhere. 


"Elsewhere" in this system means the dynamic scheduler. 


ie, 


PSDL: 
OUTPUT x, y : PSDL_EXCEPTION 
EXCEPTIONS excp1, excp2 


Ada Translation: 

exception 

when excp1 => 
DSx.PUT(psdl_excp]); 
DSy.PUT(psdl_excp1); 

when excp2 => 
DSx.PUT(psdl_excp2); 
DSy.PUT(psdl_excp2); 

when others => 
raise; 





Figure 47. Exception Closure Example 


The completed exception closure is placed into the exception closure slot 
during pass three. After the exception closure slot is filled, the translator can then 
combine all of the filled slots of the implementation template into a single Kodiyak 
String which is the atomic operator driver. The driver is placed into a map and later 
retrieved during pass four with all the other drivers that have been produced. The 
drivers are collected as a whole and placed into the atomic operator drivers slot in the 
TL package. The final TL package translation is then produced by combining all of the 
Slots of the TL package template into a single Kodiyak string. The translator then 
writes that string into a file named TL.a and the string itself is the TL package. 


80 


VI. CONCLUSIONS 


Implementing a PSDL to Ada translator is feasible. While the translator in this 
thesis is still only a partial implementation, it has demonstrated that there is a sys- 
tematic method to translate PSDL into Ada. The template method described in this 
thesis provides a clear picture of the mapping from PSDL to Ada. It is a tool which 
can be used to analyze the syntax/semantic relations between Ada and PSDL. The 
Kodiyak translator generator is an excellent tool for expressing syntax/semantic rela- 
tions between languages. By expressing the source language, PSDL, in terms of its 
abstract syntax tree it is relatively straight-forward to map branches of the abstract 
syntax tree into the specification and implementation templates derived in this the- 
sis. Kodiyak was found to be very flexible concerning changes to the grammar. Dur- 
ing design and implementation of the translator, the PSDL grammar was changed 
slightly. Incorporating those changes was very simple using Kodiyak. Changing the 
translation produced by Kodiyak was a simple process as well. In fact, the translator 
was constructed by incrementally programming the Kodiyak to perform a basic trans- 
lation and then modifying on top of that version to perform the next basic translation. 

Kodiyak does have some drawbacks, however, which were noticed during re- 
search in this thesis. Kodiyak is not a language which can be learned easily. To use 
it effectively requires a familiarity with the LEX and YACC tools in UNIX. This is no 
simple task for anything less than a seasoned programmer. Kodiyak is also an ex- 
tremely resource intensive tool. Compiling the Kodiyak source code in Appendix D 
takes just over seven minutes on a dedicated Sun 3/60 workstation. The output of 
Kodiyak is an object file over 230 kilobytes in size. Perhaps the most annoying prob- 
lem with Kodiyak is its lack of high level data types and operations. The map type is 
the only high level data type offered by Kodiyak and the operations that can be per- 
formed on it are few. Manipulating groups of objects in a map 1s cumbersome. There 
is no looping facility to allow sequencing through a group of similar objects as can be 
done in an array in Pascal or Ada. The lack of high level data types and operations 
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forces the programmer to exert more effort to manipulate data structures in a Kodiyak 
program. 

Further work is necessary to make the implementation of the translator complete. 
A static semantic analyzer is necessary. Its purpose would be to accept a PSDL pro- 
gram from the user interface system, perform a thorough semantics check on it, and if 
all is well, send the syntactically and semantically correct PSDL program to the trans- 
lator and dynamic scheduler. Type checking, timing constraint analysis, and name 
checking are the primary functions required. Currently, type checking is not particular- 
ly difficult, but when user-defined data types are eventually incorporated into the 
translator, type checking will become a serious task. Simple timing constraint analy- 
sis of PSDL operators should be performed before sending a PSDL program to the 
static scheduler. This process ensures that a composite operator’s period or maxi- 
mum execution time is sufficient to allow its subcomponents to fire comfortably. 
Name checking would ensure that composite operator names are not duplicated in a 
PSDL program. This is vital to the translator and static scheduler to guarantee that 
all of the procedure names generated by the translator are unique. 

The translator, itself, still requires some enhancements to be fully operational. 
PSDL allows the software designer to construct his own user-defined data types in 
PSDL. The translator in this thesis does not translate user-defined types, all efforts 
were devoted to PSDL operators only. PSDL exceptions are not complete. This the- 
sis has developed a conceptual design for PSDL exceptions and their semantics, how- 
ever they are not implemented in the translator. Enhancements can also be made to 
improve the visibility of PSDL timers, data streams, and operators. The present im- 
plementation depends on all names of these constructs being unique throughout a 
PSDL program. Ideally, name visibility should conform to hierarchical visibility rules. 

CAPS is dependent upon an extended compiler technique for executing PSDL pro- 
grams. This technique is a two-part process. A PSDL program’s functional behavior 
is converted to machine code via translation to an underlying conventional language 
such as Ada. The PSDL program’s temporal behavior is converted to machine code 
via a scheduling algorithm which is also implemented in a conventional language. 


These two programs are then compiled and executed together to achieve the 


82 


real-tme characteristics desired in PSDL. The research in this thesis shows that the 
translation part of the extended compiler technique is feasible and nearly complete. 
When the translator is combined with the results of research on the static and dynam- 
ic schedulers, the execution support system of the CAPS will become complete and 
automated computer aided prototyping will be significantly propelled toward reality. 
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APPENDIX A. ADA IMPLEMENTATIONS OF PSDL 
CONSTRUCTS 


A. GENERIC SAMPLED DATA STREAM PACKAGE 


with PSDL_SYSTEM; 


generic 
type ELEMENT_TYPE is private; 


package SAMPLED_STREAM is 
task DATA_STREAM 6s 
pragma PRIORITY (5); 
entry CHECK (NEW_DATA: out BOOLEAN); 
entry GET (VALUE: out ELEMENT_TYPE); 
entry PUT (VALUE: in ELEMENT_TYPE); 
end DATA_STREAM; 
function FRESH retum BOOLEAN; 
end SAMPLED_STREAM;: 


package body SAMPLED_STREAM is 


type DATA_STREAM_TOKEN 1s 
record 
INITIALIZED, 
NEW_DATA _ : BOOLEAN := false; 
VALUE : ELEMENT_TYPE; 
end record; 


task body DATA_STREAM is 
BUFFER : DATA_STREAM_TOKEN; 


begin 
loop 
select 
accept CHECK (NEW_DATA : out BOOLEAN) do 
NEW_DATA := BUFFER.NEW_DATA; 
end CHECK; 
or 
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Or 


Or 


accept GET (VALUE : out ELEMENT_TYPE) do 
if not BUFFER.INITIALIZED then 
raise PSDL_SYSTEM.BUFFER_UNDERFLOW: 
else 
VALUE := BUFFER.N_VALUE; 
BUFFER.NEW_DATA := false; 
end if; 
end GET; 


accept PUT (INVALUE : in ELEMENT_TYPE) do 
BUFFER .VALUE := INVALUE; 
BUFFER.NEW_DATA := true; 
BUFFER.INITIALIZED := true; 

end PUT; 


terminate; 


end select; 
end loop; 
end DATA_STREAM;: 


function FRESH return BOOLEAN 1s 
RESULT : BOOLEAN; 


begin 


CHECK(RESULT);: 
retum RESULT; 
end FRESH; 


generic 
type ELEMENT_TYPE is private; 


end SAMPLED_STREAM, 


B. GENERIC DATA FLOW DATA STREAM PACKAGE 


with PSDL_SYSTEM; 


package DATAFLOW_STREAM is 
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task DATA_STREAM 1s 
pragma PRIORITY (5); 
entry CHECK (NEW_DATA : out BOOLEAN); 
entry GET (VALUE: out ELEMENT_TYPE); 
entry PUT (VALUE: in ELEMENT_TYPE); 
end DATA_STREAM,; 


function FRESH return BOOLEAN; 
end DATAFLOW_STREAM; 


package body DATAFLOW_STREAM 1s 


type DATA_STREAM_TOKEN 1s 
record 
INITIALIZED, 
NEW _DATA_ : BOOLEAN := false; 
VALUE : ELEMENT_TYPE; 
end record; 


task body DATA_STREAM 1s 
BUFFER : DATA_STREAM_TOKEN; 


begin 
loop 
select 
accept CHECK (NEW_DATA : out BOOLEAN) do 
NEW_DATA := BUFFER.NEW_DATA; 
end CHECK; 


or 
accept GET (OUTVALUE : out ELEMENT_TYPE) do 
if not (BUFFER.INITIALIZED and BUFFER.NEW_DATA) then 
raise PSDL_SYSTEM.BUFFER_UNDERFLOW;: 
else 
OUTVALUE := BUFFER.VALUE; 
BUFFER.NEW_DATA := false; 
end if; 
end GET; 


Or 


accept PUT (INVALUE : in ELEMENT_TYPE) do 
if BUFFER.NEW_DATA then 
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raise PSDL_ SYSTEM.BUFFER_OVERFLOW; 
else 
BUFFER.VALUE := INVALUE; 
BUFFER.NEW_DATA := true; 
BUFFER.INITIALIZED := true; 
end if; 
end PUT; 


or 
terminate; 
end select; 
end loop; 
end DATA_STREAM; 


function FRESH return BOOLEAN is 
RESULT : BOOLEAN; 

begin _= 

CHECK(RESULT); 
retum(RESULT); 

end FRESH; 


end DATAFLOW_STREAM; 
C. GENERIC SAMPLED STATE VARIABLE PACKAGE 


with PSDL_SYSTEM; 


generic 
type ELEMENT_TYPE is private; 
INITIAL_VALUE : ELEMENT_TYPE; 


package SAMPLED _STATE_VAR is 


task DATA_STREAM is 
pragma PRIORITY (5); 
entry CHECK (NEW_DATA : out BOOLEAN); 
entry GET (VALUE: out ELEMENT_TYPE); 
entry PUT (VALUE: in ELEMENT_TYPE); 
end DATA_STREAM; 
function FRESH return BOOLEAN: 
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end SAMPLED STATE_VAR; 


package body SAMPLED_STATE_VAR is 
type DATA_STREAM_TOKEN is 
record 
INITIALIZED, 
NEW_DATA_ : BOOLEAN := false; 
VALUE : ELEMENT_TYPE := INITIAL_VALUE; 
end record; 


task body DATA_STREAM is 
BUFFER : DATA_STREAM_TOKEN; 


begin 
loop 
select 
accept CHECK (NEW_DATA : out BOOLEAN) do 
NEW_DATA := BUFFER.NEW_DATA; 
end CHECK; 


or 
accept GET (OUTVALUE : out ELEMENT_TYPE) do 
if not BUFFER.INITIALIZED then 
raise PSDL_SYSTEM.BUFFER_UNDERFLOW,; 
else 
OUTVALUE := BUFFER.VALUE; 
BUFFER.NEW_DATA := false; 
end if; 
end GET; 


or 
accept PUT (INVALUE: in ELEMENT_TYPE) do 
BUFFER.VALUE := INVALUE; 
BUFFER. INITIALIZED := true, 
BUFFER.NEW_DATA §$:= true, 
end PUT; 


or 
terminate; 
end select; 
end loop; 
end DATA_STREAM; 
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function FRESH return BOOLEAN is 
RESULT : BOOLEAN; 

begin 
CHECK(RESULT),; 
retum RESULT; 

end FRESH; 


end SAMPLED_STATE_VAR; 
D. GENERIC DATA FLOW STATE VARIABLE PACKAGE 


with PSDL_SYSTEM; 


generic 
type ELEMENT_TYPE is private; 
INITIAL VALUE : ELEMENT_TYPE; 


package DATAFLOW_STATE_VAR is 


task DATA STREAM is 
pragma PRIORITY (5); 
entry CHECK (NEW_DATA : out BOOLEAN); 
entry GET (VALUE: out ELEMENT_TYPE); 
entry PUT (VALUE: in ELEMENT_TYPE); 
end DATA_STREAM;: 


function FRESH retum BOOLEAN; 
end DATAFLOW_STATE_ VAR; 


package body DATAFLOW_STATE_VAR is 


type DATA_STREAM_TOKEN is 
record 
INITIALIZED, 
NEW_DATA_: BOOLEAN := false; 
VALUE : ELEMENT_TYPE :=INITIAL_VALUE; 
end record; 


task body DATA_STREAM is 
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BUFFER : DATA_STREAM_TOKEN; 
begin 
loop 
select 
accept CHECK (NEW_DATA : out BOOLEAN) do 
NEW_DATA := BUFFER.NEW_DATA; 
end CHECK; 


or 
accept GET (OQUTVALUE : out ELEMENT_TYPE) do 
if not (BUFFER.INITIALIZED and BUFFER.NEW_DATA) then 
raise PSDL_ SYSTEM.BUFFER_UNDERFLOW; 
else 
OUTVALUE := BUFFER.VALUE; 
BUFFER.NEW_DATA := false; 
end if: 
end GET; 


or 
accept PUT (INVALUE : in ELEMENT_TYPE) do 
if BUFFER.NEW_DATA then 
raise PSDL_SYSTEM.BUFFER_ OVERFLOW; 
else 
BUFFER.VALUE := INVALUE; 
BUFFER.NEW_DATA := true; 
BUFFER.INITIALIZED := true: 
end if; 
end PUT; 


or 
terminate; 
end select; 
end loop; 
end DATA_STREAM; 


function FRESH return BOOLEAN is 
RESULT : BOOLEAN; 

begin 
CHECK(RESULT); 
retum(RESULT),; 

end FRESH; 


end DATAFLOW_STATE_VAR; 
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E. GENERIC TIMER PACKAGE 


with PSDL_SYSTEM,; 
package PSDL_TIMER is 
subtype MILLISEC is new PSDL_SYSTEM.TIMER; 


procedure RESET ; 
procedure START ; 
procedure STOP ; 
function READ return MILLISEC; 


end PSDL_TIMER; 


with CALENDAR; 
use CALENDAR; 
package body PSDL_TIMER is 


type STATE is (INITIAL, RUNNING, STOPPED), 
type TIMER is 
record 
START_TIME, 
STOP_TIME :CALENDAR.TIME; 
ELAPSED_TIME : DURATION; 
PRESENT STATE: STATE; 
end record; 


WATCH : TIMER: 


function READ return MILLISEC is 
CONVERSION_FACTOR : constant DURATION := 1000.0; -- Converts to 
begin : -- milliseconds 
case PRESENT STATE is 


when RUNNING => return MILLISEC((CLOCK 
- WATCH.START_TIME 
+ WATCH.ELAPSED_TIME) 
* CONVERSION_FACTOR); 
when others => return MILLISEC(WATCH.ELAPSED_TIME); 
end case; 
end READ; 


9] 


procedure RESET is 


begin 
case WATCH.PRESENT_STATE 1s 
when STOPPED => WATCH.ELAPSED_TIME := 0.0; 
WATCH.PRESENT_STATE := INITIAL; 
when others => null; 
end case; 
end RESET; 


procedure START is 


begin 
case WATCH.PRESENT_STATE is 
when RUNNING) => null; 
when others => WATCH.START_TIME := CALENDAR.CLOCK; 
WATCH.PRESENT_STATE := RUNNING; 
end case; 
end START; 


procedure STOP is 


begin 
case WATCH.PRESENT_STATE 1s 
when RUNNING => WATCH.ELAPSED_TIME := CALENDAR.CLOCK 
- WATCH.START_TIME 
+ WATCH.ELAPSED_TIME,; 
WATCH.PRESENT_STATE := STOPPED; 


when others => null; 
end case; 


end STOP; 


end PSDL_TIMER; 
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APPENDIX B. SPECIFICATION PACKAGE TRANSLATION 
EXAMPLE 


The purpose of this example is to demonstrate the translation of a composite oper- 
ator into a set of specification packages. The PSDL rules of visibility state that data 
streams declared in a composite operator are visible to the composite operator’s sub- 
components. The difficulty to overcome in this thesis was finding a way to allow this 
sort of hierarchical visibility structure in a flat physical structure. 

This example takes a simple PSDL operator and decomposes it into its subcompo- 
nents. A data flow diagram 1s presented to show the hierarchical structure of a PSDL 
operator and the data streams at each operator. The PSDL representation of the data 
flow diagram 1s then shown. Finally, the PSDL program is translated into a set of 
specification packages which demonstrates the flat structure of the Ada representa- 
tion and how the lines of visibility can be established using the Ada with and re- 


mames clauses. 


A. DATA FLOW DIAGRAM 





B. PSDL REPRESENTATION OF DATA FLOW DIAGRAM 


OPERATOR Cl 
SPECIFICATION 
STATES a: INTEGER INITIALLY 0, 
b: FLOAT INITIALLY 1.0; 
END 


IMPLEMENTATION GRAPH 
a.EXTERNAL -> C2 
b.EXTERNAL -> C2 
a.C3 -> EXTERNAL 
b.C3 -> EXTERNAL 
c.C2 -> C3 
d.C2 -> C3 


DATA STREAM c,d : INTEGER; 
CONTROL CONSTRAINTS 
OPERATOR C2 
PERIOD 200 
OPERATOR C3 
PERIOD 200 
DESCRIPTION 
{ This 1s the root operator. It is not allowed to have any external input or output 
data streams. To get information into the system, state variables are used. Note 
that the subcomponents are composite operators also, thus they may not have 
any control constraints like triggers, outputs, tumers, or exceptions. } 
END 


OPERATOR C2 
SPECIFICATION 
INPUT a: INTEGER, 
b : FLOAT 
OUTPUT c,d : INTEGER 
END 


IMPLEMENTATION GRAPH 
a.EXTERNAL -> Al 
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b.EXTERNAL -> A2 
c.A2 -> EXTERNAL 
d.A2 -> EXTERNAL 
e.Al -> A2 


DATA STREAM e : FLOAT 


CONTROL CONSTRAINTS 
OPERATOR Al 
TRIGGERED IF a >= 0 
OPERATOR A2 
TRIGGERED BY SOME b 
OUTPUT c IF c>0 
DESCRIPTION 
{ Operator C2 is a composite operator with atomic subcomponents AI and A2. 
Operator C3 requires visibility to all of its parent’s data streams, a, b, c, and d. } 
END 


OPERATOR C3 
SPECIFICATION 
INPUT c,d : INTEGER 
OUTPUT a : INTEGER, 
b : FLOAT 
END 


IMPLEMENTATION GRAPH 
c.EXTERNAL -> A3 
d.EXTERNAL -> A4 
a.A4 -> EXTERNAL 
b.A4 -> EXTERNAL 
f.A3 -> A4 


DATA STREAM f : FLOAT 


CONTROL CONSTRAINTS 
OPERATOR A3 


OD 


TRIGGERED 
OPERATOR A4 
TRIGGERED 
DESCRIPTION 
{ Operator C2 is a composite operator with atomic subcomponents A3 and A4. 
Operator C3 requires visibility to all of its parent’s data streams, a, b, c, and d. } 
END 


OPERATOR Al 
SPECIFICATION 
INPUT a : INTEGER 
OUTPUT e : FLOAT 
END 


IMPLEMENTATION ADA AI { The atomic operator Al requires visibility to data 
streams a and e in C2. } 
END 


OPERATOR A2 
SPECIFICATION 
INPUT b,e : FLOAT 
OUTPUT c,d : INTEGER 
END 


IMPLEMENTATION ADA A2 { The atomic operator A2 requires visibility to data 
streams b, c, d, ande in C2 } 
END 


OPERATOR A3 
SPECIFICATION 
INPUT c : INTEGER 
OUTPUT f : FLOAT 
END 


IMPLEMENTATION ADA _ A3 (The atomic operator A3 requires visibility to data 
streams c and f in C3} 
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OPERATOR A4 
SPECIFICATION 
INPUT d : INTEGER, 
f : FLOAT 
OUTPUT a: INTEGER 
b : FLOAT 
END 


IMPLEMENTATION ADA A4 { The atomic operator A4 requires visibility to data 
streams a, b, d, and f in C3. } 
END 


C. ADA SPECIFICATION PACKAGES FOR OPERATORS Cl, C2, C3, Al, 
AND A3 


package Cl_SPEC 1s 
-- This is the specification package for the root operator. It instantiates data 
-- streams a, b, c, and d. 


package DSa is new SAMPLED_STATE_VAR(INTEGER,0); 
package DSb is new SAMPLED_STATE_VAR(FLOAT, 1.0): 
package DSc is new SAMPLED_STREAM(INTEGER); 
package DSd is new SAMPLED_STREAM(FLOAT); 

end Cl_SPEC; 


with Cl SPEC; 

package C2_SPEC 1s 

-- This is the specification package for composite operator C2. It establishes a link 
-- with its parent, C1, via the statement with Cl SPEC. Visibility is required to 
-- data streams a, b, c, and d. 


package DSa renames C1_SPEC.DSa; 

package DSb renames C1_SPEC.DSb; 

package DSc renames C1_SPEC.DSc; 

package DSd renames C1_SPEC.DSd; 

package DSe is new SAMPLED_STREAM(FLOAT); 
end C2_ SPEC; 
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with C1l_SPEC; 

package C3_SPEC is 

-- This is the specification package for operator C3. It requires visibility to data 
-- Streams a, b, c, and d in Cl_ SPEC. 


package DSa renames Cl_SPEC.DSa; 

package DSb renames C1_SPEC.DSb; 

package DSc renames Cl1_SPEC.DSc; 

package DSd renames C1_SPEC.DSd; 

package DSf is new SAMPLED_STREAM(FLOAT); 
end C3-SPEC; 


with C2_ SPEC; use C2_ SPEC; 
procedure C2_A\| is 
TL_a : INTEGER; 
TL_e : FLOAT; 
begin 
loop 
if true then 
DSa.GET(TL_a); 
if TL_a>= 0 then 
A1l(TL_a, TL _e): 
DSe.PUT(TL_e); 
end if: 
end if; 
exit; 
end loop; 
end C2_ Al; 


with C3_SPEC; use C3_ SPEC; 
procedure C3_A3 is 
TL_c : INTEGER; 
ThA EEO Ag:. 
begin 
loop 
if true then 
DSc.GET(TL_c); 
if true then 
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A3(TL_c,TL_f); 
DSf.PUT(TL_f); 
end if: 
end if; 
exit; 
end loop; 
end C3_A3; 
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APPENDIX C. PSDL GRAMMAR 


The conventions used for symbology in this grammar are standard. (Curly brac- 
es} indicate item which may appear zero or more times. [ Square brackets ] indicate 
items which may appear zero or one time in a rule. Bold face items are terminal key- 


word symbols in the grammar. ‘Double quotes" indicate character literals in the 


grammar. The "I" vertical bar indicates a list of options from which no more than one 


item may be selected. This grammar represents the updated version of the PSDL 


grammar as of 26 Oct 1988. 


Start = psdl 

psdi = { component } 

component = data_type | operator 

data_type = type id type_spec type_impl 

operator = operator 1d operator_spec operator_impl 


type_spec = specification [type_decl] {operator id operator_spec} 
[functionality] end 


type_impl = implementation ada id "{" text "}" 
| implementation type_name (operator id operator_impl} end 


operator_spec = specification {interface} [functionality] end 


operator_impl! = implementation ada id "{" text "}" 
| implementation psdl_impl 


type_decl = 1d_list ":" type_name {"," id_list ":" type_name} 
functionality = [keywords] [informal_desc] [formal_desc] 
psdl_impl = data_flow_diagram [streams] [timers] [control_constraints] 


[informal_desc] end 
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type_name = id '[" type_decl "]" 
| id 


interface = attribute [reqmts_trace] 
id_list=id (",' id } 
keywords = keywords id_list 
informal_desc = description "{" text "}" 
formal_desc = axioms "{" text "}" 
data_flow_diagram = graph {link} 
streams = data stream type_dec! 
timers = timer id_list 
attribute = generic_param 
| input 
| output 
| states 
| exceptions 
\ timing info 
generic_param = generic type_decl 
input = input type_decl 
output = output type_decl 
states = states type_decl initially expression_list 
exceptions = exceptions id_list 
timing info = [maximum execution time time] 
{minimum calling period time] 
[maximum response time time] 
reqmts_trace = by requirements id_list 
link =id "." id [":" time] "->" id 


control_constraints = control constraints {constraint} 
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constraint = operator id 
[triggered [trigger] [tf predicate] [reqmts_trace]] 
[period time [reqmts_trace]] 
[finish within time [reqmts_trace]] 
{constraint_options} 


trigger = by all id_list 
| by some id_list 


constraint_options = output id_list if predicate [reqmts_trace] 
| exception id [if predicate] [reqmts_trace] 
| timer_op id [if predicate] [reqmts_trace] 


timer_op = read timer 
| reset timer 
| start timer 
| stop timer 


te otf 


expression_list = expression {', expression} 
time = integer [unit] 
unit = ms/sec!min/ hours 


expression = constant 
lid 
| type_name "." id "(" expression_list ")" 
predicate = relation {bool_op relation} 


relation = sunple_expression 
| simple_expression rel_op simple_expression 


simple_expression = [sign] integer [unit] 
| [sign] real 
| [not] id 
| string 
| [not] "(" predicate ")" 
| [not] boolean_constant 
bool_op = and | or 


rel_op= ad | "en" | i | "Ss" | a | "=" | seo 


1Q2 


fe otf 


real = integer .” integer 

integer = digit ( digit} 

boolean_constant = true | false 
numeric_constant = real | integer 

constant = numeric_constant | boolean_constant 
sign = "+" | "-" 

char = any printable character except "}" 
ait — “(0 .. 9" 

fiter= a..zili'A..Z' |" " 
alpha_numeric = letter | digit 

id = letter {alpha_numeric} 


string _— rere ee { char} terres 


text = {char} 


1Q3 


APPENDIX D. KODIYAK PROGRAM LISTING 


The following is a listing of the Kodiyak program used to generate the translator in 
this thesis. It is based upon the Kodiyak program produced by Moffitt in [Ref. 17]. 
This program is capable of producing a translator which will translate a subset of the 
PSDL grammar. The constructs not translated by this version include: 


- PSDL exceptions. 
- User-defined types. 


{definitions of lexical classes 


J%define Digit :[0-9] 

%define Int :{ Digit }+ 
%define Letter :[a-zA-Z_] 
Jodefine Alpha :({ Letter }1{Digit}) 
%define Blank :{ \t\nJ 

Ydefine Char [ACh] 

%define Quote a hea 


! definitions of white space 
:{ Blank }+ 


! definitions of compound symbols and keywords 


GiE =a 

LTE —<—s 

NEQV f=" 

ARROW a Po 

TYPE :typeITYPE 
OPERATOR :operatorlIOPERATOR 
SPECIFICATION :specification|IS PECIFICATION 
END -endIEND 

GENERIC :genericlIGENERIC 
INPUT sinputIINPUT 
OUTPUT :outputOUTPUT 
STATES :statesISTATES 
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INITIALLY 
EXCEPTIONS 
NORMAL 
MAX_EXEC_TIME 


‘initially INITIALLY 
-exceptionsIEXCEPTIONS 
:normalINORMAL 


‘maximum Jexecution[ ]JttmeIMAXIMUM[ JEXECUTION|[ ]TIME 


MAX_RESP_TIME 


:maximun] Jresponse[ JtimelMAXIMUM|[ JRESPONSE[ ]TIME 


MIN_CALL_PERIOD 


:minimun{ Jcalling[ ]periodIMINIMUM[ ]CALLING[ ]PERIOD 


MS 

SEC 

MIN 

HOURS 

BY 
KEYWORDS 
DESCRIPTION 
AXIOMS 
IMPLEMENTATION 
ADA 

GRAPH 
DATA_STREAM 
TIMER 
CONTROL 
TRIGGERED 
ALL 

SOME 
PERIOD 
FINISH 
EXCEPTION 
READ 

RESET 

START 

STOP 

IF 

NOT 

AND 

OR 

TRUE 


:msIMS 


ssecISEC 

:minIMIN 

shoursIHOURS 

-by[ JrequirementsIBY[ JREQUIREMENTS 


-keywordsIKE YWORDS 
:descnptionIDES CRIPTION 
saxiomslIAXIOMS 

:implementation IMPLEMENTATION 


sadalAdalADA 


:graphIGRAPH 
:data[ ]streamIDATA[ JSTREAM 
stimerlI TIMER 


:control[ JconstraintsICONTROL[ JCONSTRAINTS 
:triggered/ TRIGGERED 

by[ JallIBY[ JALL 

=by[ JsomelBY[ JSOME 

:periodIPERIOD 


:finish[ }withinIFINISH[ ]WITHIN 
-exceptionIEXCEPTION 
‘read[ JtimerlIREAD[ JTIMER 
‘reset[ JtumerlIRESET[ JTIMER 
:start[ JtimerlSTART[ JTIMER 
:stop[ JttmerISTOP[ ] TIMER 
siflIF 

=" 1 "not" | "NOT" 

"&" | "and" | "AND" 

Tb "or" "OR" 

‘trueITRUE 
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FALSE :falselFALSE 

ID :{ Letter} { Alpha }* 
STRING_LITERAL :{ Quote } { Char} * { Quote } 
INTEGER_LITERAL — :{Int} 


REAL_LITERAL Oise Oley 
TEXT “"("tChary |" 
! operator precedences 


! %left means group and evaluate from the left 


%left OR; 

%ileft AND; 

%left NOT; 

Jleft °<’,’>’, =’, GTE, LTE, NEQV; 
%left °:’; 


Jo% 
! attribute declarations for nonterminal symbols 


Start { trn: string; }; 
psdl { trn: string; 
uncond_output_map:string->string; 
out_env:string->string; 
in_env:string->string; }; 
component { tm: string; 
uncond_output_map_in:string->string; 
uncond_output_map_out:string->string; 
in_env:string->string; 
out_env:string->string; }; 


data_type { trn: string; 
in_env:string->string; }; 

operator { tm: string; 
uncond_output_map_in:string->string; 
uncond_output_map_out:string->string; 
in_env:string->string; 
out_env:string->string; }; 
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type_spec { tm: string; 
in_env:string->string; }; 
type_decl_1_list { trn: string; 
in_env:string->string; }; 
type_decl { trn: string; 
in_env,out_env :string->string; 
opid:string; 
action_code:string; 
ucond_output:string; }; 


op_spec_O_list { tm: string; 
in_env:string->string; }; 


operator_spec { opid:string; 
ds_decl:string; 
State_decl:string; 
ucond_output:string; 
excp_decl:string; 
in_env,out_env :String->string; } 


interface { in_env,out_env :string->string; 
in_parm, out_parm : string; 
ds_decl: string; 
State_decl:string; 
excp_decl:string; 
ucond_output:string; 
opid:string; }; 


attribute { ds_decl: string; 
in_env,out_env :string->string; 
in_parm, Out_parm: string; 
opid:string; 
State_decl:string; 
ucond_output:string; 
excp_decl:string; }; 


time { tm: string; }; 
unit { value: int; }; 
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id_list { tm: string; 
action_code:string; 
tname:string; 
opid:string; 
ucond_output:string; 
count : int; 
exp_env:int->string; 
in_env:string->string; 
out_env:string->string; }; 


reqmts_trace { tm: string; }; 
functionality { trn: string; }; 
keywords { tn: string; }; 
informal_desc { tm: string; }; 
formal_desc { tr: string; }; 
type_imp! { tm: string; }; 
op_impl_O_list { tm: string; }; 
operator_impl { trn: string; 
out_env:string->string; 
in_env:string->string; 
uncond_output_map:string->string; 
loc_ds_decl:string; 
timer_decl:string; 
opid:string; }; 
psdl_impl { tm: string; 
parent : string; 
uncond_output_map:string->string; 
in_env:string->string; 
out_env:string->string; 
loc_ds_decl:string; 
timer_decl:string; }; 


data_flow_diagram { tm: string; 
in_env, decl_map : string-> string; }; 


link_Q_list { trn: string; 
in_env,in_decls,out_decls : string->string; }; 
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link { tm: string; 
in_env,in_decls,out_decls : string->string; }; 


opt_time { tm: string; }; 
type_name { tn: string; }; 
timers { tr: string; }; 
control_constraints { trn: string; 
parent : string; 
uncond_output_map:string->string; 
in_env:string->string; 
out_env:string->string; 
decl_map : string->string; 
He 
constraint_options { tm: string; 
in_env: string->string; 
out_env:string->stning; 
opid:string; 
le 
more_constraints {tm : string; 
parent:string; 
uncond_output_map:string->string; 
in_env:string->string; 
out_env:string->string; 
decl_map : string->string; 
}; 
opt_tng { out_env:string->string; 
in_env: string->string; 
streams_check:string; 
end_if_streams:string; 
pred:string; 
end_if_pred:string; 
if 


trigger {if: string; 

end_if:string; 

in_env, out_env:string->string; }; 
opt_per { tm: string; }; 
opt_fin_w { trn: string; }; 
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Streams {trn: string; 
in_env,out_env :string->string; }; 
timer_op { trn: string; }; 
opt_if_predicate { if: string; 
end_if:string; 
parent:string; 
in_env : String-> string; }; 
predicate { tm: string; 
in_env: string->string; 
type: string; }; 
expression_list { trn: string; 
count:int; 
exp_env:int->string; }; 
expression { trn: string; }; 
relation {trn: string; 
in_env: string->string; 
type: string; }; 
simple_expression { trn: string; 
parent: string; 
in_env: string->string; 
type:string; }; 
rel_op {trn: string; 
left_op:string; 
right_op: string; 
' Opn_type: string; 
parent: string; }; 
sign {trn: string; }; 


!attrbute declarations for terminal symbols 


ID{ %text: string; }; 

TEXT { %text: string; }; 
STRING_LITERAL{ %text: string; }; 
INTEGER_LITERAL{ %text: string; }; 
REAL LITERAL {%text: string; }; 


ToT 
!psdl grammar 
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Start 
: psdl 
{ Zoutput(["with PSDL_SYSTEM;\nuse PSDL_SYSTEM;\npackage TL is\n", 
psdl.trn,"end TL;\n")); 
psdl.in_env = psdl.out_env; 


} 


psdl 
> component psdl 
{ psdl[1].tm = [component.tm, '\n",psdl[2].tm]; 

psdl[1].out_env = component.out_env +! psdl[2].out_env; 

psdi{1].uncond_output_map = component.uncond_output_map_out 
+| psd]{2].uncond_output_map; 

component.in_env = psdl[1].in_env; 

component.uncond_output_map_in = psd1[2].uncond_output_map; 

psdl[2].in_env = psdl[1].in_env ; 


| 
{ psdl.trn = on | 
psdl.out_env = {(?:string:"")}; 
psdl.uncond_output_map = {(?:string:""")} ; 


component 
: data_type 
{ component.tm = ""; 
component.out_env = {(?:string:""")}; 
component.uncond_output_map_out = {(?:string:"")}; 
data_type.in_env = component.in_env; 


} 


| operator 
{ component.trn = operator.trn; 
component.out_env = operator.out_env; 
component.uncond_output_map_out = operator.uncond_output_map_out; 
operator.in_env = component.in_env; 


11] 


operator.uncond_output_map_in = component.uncond_output_map_in; 


data_type 
: TYPE ID type_spec type_impi 
{ data_type.trn = ""; 
type_spec.in_env = data_type.in_env; 
} 


operator 
: OPERATOR ID operator_spec operator_imp]l 
{ operator.tm = 
(operator.in_env(ID.%text*" CONSTRUCT") == "composite_operator” 
-> ["\npackage ", 
ID.%text,_SPEC is\n" ,operator_spec.ds_decl,'\n", 
operator_impl.loc_ds_decl,'\n", 
operator_spec.state_decl,'\n", 
operator_impl.timer_decl,'\n", 
operator_spec.excp_decl,'\nend ", 
ID.%text,""_SPEC;\n" ,operator_impl.trn] 
re 
); 
operator.uncond_output_map_out = 
{ ID.%text:operator_spec.ucond_output) }; 


operator_spec.opid = ID.%text; 

operator_spec.in_env = operator.in_env; 

operator_impl.opid = ID.%text; 

operator_impl.in_env = {("PARENT":ID.%text)} +] operator.in_env; 
operator_impl.uncond_output_map = operator.uncond_output_map_in; 
operator.out_env = operator_spec.out_env +l operator_impl.out_env; 


type_spec 
: SPECIFICATION type_decl_1_list op_spec_O_list functionality END 


bl\2 


t typexspec.tm = °"; 
_decl_1_list.in_env = type_spec.in_env; 
op_spec_Q_list.in_env = type_spec.in_env; 


} 


type_decl_1_list 
: type_decl 
{ type_dec]_1_list.trn = type_decl.tm; 
type_decl.action_code = "type"; 
type_decl.in_env = type_decl_1_list.in_env; 
} 


| 
{type_decl_1_list.trn = "";} 


type_decl 
> id_list ’:’ type_name 
{ type_decl.trn = id_list.trn; 
type_decl.out_env = id_list.out_env; 
type_decl.ucond_output = id_list.ucond_output; 
id_list.in_env = type_decl.in_env; 
id_list.action_code = type_decl.action_code; 
id_list.name = type_name.trn; 
id_list.opid = type_decl.opid; 
id_list.count = 1; 
id_list.exp_env = {(?:int:"")}; 


lid_list ’:’ type_name ’,’ type_decl 
{ type_decl[1].trn = id_list.trn “ type_decl[2].trn; 
_decl[1]}.out_env = 1d_list.out_env +1 type_decl[2].out_env; 
type_decl.ucond_output = id_list.ucond_output 
“ type_decl[2].ucond_output; 


id_list.in_env = type_decl[1].1n_env; 
id_list.action_code = type_decl[1].action_code; 


ns 


id_list.tname = type_name.tm; 

id_list.opid = type_decl{1].opid; 

id_list.count = 1; 

id_list.exp_env = {(?:int:"")}; 

type_decl[2].in_env = type_decl[1].1n_env; 
type_decl[2].opid = type_decl[1].opid; 
type_decl[2].action_code = type_decl[1].acttion_code; 


op_spec_O_list 
: op_spec_O_list OPERATOR ID operator_spec 
{ op_spec_O_list[1].trn = ""; 
operator_spec.in_env = op_spec_O_list.in_env; 
op_spec_Q_list[2].1n_env = op_spec_O_list[1].in_env; 
} 
| 


{ op_spec_O_list.trn = ""; } 


operator_spec 
: SPECIFICATION interface functionality END 
{ operator_spec.ds_decl = interface.ds_decl; 
operator_spec.state_decl = interface.state_dec]; 
operator_spec.excp_decl = interface.excp_dec]; 
operator_spec.ucond_output = interface.ucond_output; 
operator_spec.out_env = 
(interface.out_env(operator_spec.opid*"INPARM") == "" II 
interface.out_env(operator_spec.opid“" OUTPARM") == "" 
-> {((operator_spec.opid*"PROCCALL'"): 
[interface.out_env(operator_spec.opid*"INPARM"), 
interface.out_env(operator_spec.opid*"OUTPARM")])} 
# {((operator_spec.opid*"PROCCALL"): 
[interface.out_env(operator_spec.opid4"INPARM"),",", 
interface.out_env(operator_spec.opid*"OUTPARM")]) } 
) +l interface.out_env; 


interface.in_env = operator_spec.in_env; 
interface.opid = operator_spec.opid; 
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interface 
: interface attribute reqmts_trace 
{ interface[1].ds_decl = 
[interface[2].ds_decl,'\n" ,attribute.ds_decl]; 
interface[1].state_decl = 
[interface[2].state_decl,'\n" attribute.state_decl]; 
interface[ 1].excp_decl = 
[interface[2].excp_decl,'\n",attribute.excp_decl]; 
interface[1].in_parm = interface[2].1n_parm “ attribute.in_parm; 
interface[1].out_parm = interface[2].out_parm “ attribute.out_parm; 


interface[1].out_env = 
{ (interface[1].opid*" INPARM"):interface[1].in_parm) 
((interface[1].opid*"OUTPARM'"):interface[1].out_parm) } 
+| interface[2].out_env +l attribute.out_env; 


interface[1].ucond_output = interface[2].ucond_output 
“ attribute.ucond_output; 


interface[2].opid = interface[1].opid; 
interface[2].in_env = interface[1].in_env; 
attribute.in_env = interface[1].in_env; 
attribute.opid = interface[1].opid; 


ttt. 


{interface.ds_decl = °"; 
interface.state_decl = ""; 


To 


interface.excp_decl = ""; 


interface.in_parm ="; 
interface.out_parm = ""; 
interface.out_env = {(?:string:"")}; 
interface.ucond_output = ""; 


Jig) vs 


attribute 
: GENERIC type_decl 
{ type_decl.action_code = ""; 
type_decl.opid = Mek ori: 
_decl.in_env = attribute.in_env; 

attribute.out_env = type_decl.out_env; 
attribute.ds_decl = ""; 
attribute.state_decl = 
attribute.excp_decl = 
attribute.in_parm = 
attribute.out_parm = 
attribute.ucond aaa 


ett, 

ete, 
eet, 
ttt, 


| INPUT type_decl 

{ type_decl.action_code = "input"; 
type_decl.opid = attribute.opid; 
type_decl.in_env = attribute.in_env; 
attribute.out_env = type_decl.out_env; 
attribute.ds_decl = type_decl.trn; 
attribute.state_decl ="; 
attribute.excp_decl ="; 
attribute.in_parm = PE decl.out_env(attribute.opid*"INPARM"); 
attribute.out_parm = "" 

attribute ubscmeone: ="; 


| OUTPUT type_decl 
{ type_decl.action_code = "output"; 
type_decl.opid = attribute.opid; 
_decl.in_env = attribute.in_env; 
attribute.out_env = type_decl.out_env; 
attribute.ds_decl = type_decl.trn; 
attribute.state_decl = ""; 
attribute.excp_decl = ""; 
attribute.in_parm = ""; 
attribute.out_parm = ie decl.out_env(attribute. opid4"OUTPARM"); 
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attribute.ucond_output = type_decl.ucond_output; 


| STATES id_list ’:’ ID INITIALLY expression_list 
{ id_list.action_code = "States"; 

id_list.opid = attribute.opid; 
id_list.name = ID. %text; 
id_list.count = 1; 
id_list.exp_env = expression_list.exp_env; 
id_list.in_env = attribute.in_env; 
expression_list.count = 1; 
attribute.out_env = id_list.out_env; 
attribute.ds_decl = ""; 
attribute.state_decl = id _list.trn; 
attribute.excp_decl = ""; 
attribute.1in_parm = 


attribute.out_parm = 
attribute.ucond Pai oe 


| EXCEPTIONS id_list 
{ id_list.action_code = "excp"; 

id_list.tname = “exception’; 
id_list.opid = attribute.opid; 
id_list.count = 1; 
id_list.exp_env = {(?:nt:"")}; 
id_list.in_env = attribute.in_env; 
attribute.out_env = id_list.out_env; 
attribute.ds_decl = °"; 
attribute.state_decl = ""; 
attribute.excp_decl = id list.tmn," : PSDL_EXCEPTION;\n"}; 
attribute.in_parm = ""; 

attribute.out_parm = 

attribute.ucond ee nak 
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|MAX_EXEC_TIME tume 
{ attribute.ds_decl = ""; 
attribute.state_decl = ""; 
attribute.excp_decl = ""; 
attribute.out_env = {(?: string:'"")}: 
attribute.in_parm = ""; 
attribute.out_parm = 
attribute.ucond ear 


eet, 


| MIN_CALL_PERIOD time 
{ attribute.ds_decl = °": 
attribute.state_decl = 
attribute.excp_decl = 
attribute.out_env = {(?: — se) te 
attribute.in_parm ="; 
attribute.out_parm = om 
attribute.ucond_output = ""; 


JU. 


ett, 


|MAX RESP TIME time 
{ attribute.ds_decl = 

attribute.state_decl ="; 
attribute.excp_decl ="; 
attribute.out_env = {(?: iiet: wate 
attribute.in_parm = ""; 
attribute.out_parm = 
attribute.ucond mae = 


ttt, 


tt, 


id_list 
: ID ’,’ id_list 
{ id_list[1].trn = 
(id_list[1].action_code == "input" II 
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id_list{1].action_code == "output" 
-> (id_list({1].in_env(id_list[1].opid*" PARENT") == "" 
-> ["package DS", ID.%text," is new ", 
(id_list[1].in_envdD.%text*"BUFF_TYPE") == "fifo" 
-> "FIFO_BUFFER" 
# "SAMPLED_BUFFER") 
»C",1d_list[1].tname,");\n"] 
# ["package DS",ID.%text," renames ", 
id_list{1].in_env(id_list[1].opid“"PARENT"),"_SPEC.DS", 
ID.%text,";\n"}) 4 1d_list[2].trn 


# id_list[1].action_code == ''states" 
-> ["package DS" ID. %text," is new STATE_VARIABLE(’, 


id_list[1].tname,", ",id_list{1].exp_env(id_list{1].count), 
"YAn"] 4 1d_hist[2].tm 


a id_list{1].action_code == "excp' 
-> ["EX" ID. %text,",",1d_list[2].trn] 


# id_list{1].action_code == "stream" 
-> ["package DS" ID.%text," 1s new ", 
(id_list[1].in_env(ID.%text“4"BUFF_TYPE") == "fifo" 
-> "FIFO_BUFFER" 
# "SAMPLED_BUFFER"), "(’,1d_hst[1].tname,");\n"] 
A 1d_list{2].tm 


# 1d_list{1].action_code == “timer” 
-> ["TL" ID. %text,",” ,id_list[2].trm] 


# 1d_list{1].action_code == “by_all" 
-> [id_list[1].opid,"_SPEC.DS",ID.%text,". NEW_DATA",” AND \n", 
id_list{2].trn] 


# id_list[1].action_code == "by_some"™ 
-> [id_list[1].opid,"_SPEC.DS" ,ID.%text,". NEW_DATA"," OR \n", 
id_list[2].trn] 
# id_list[1].action_code == "co_output" 


hy, 


-> [id_list({1].in_env(id_list[1].opid*" PARENT"),"_SPEC.DS", 
ID.%text,".WRITE(", ID. %text,");\n",id_hst[2].tmn] 


# mee 


id_list[2].in_env = id_list[1].1n_env; 

id_list[2].action_code = id_list[1].action_code; 

id_list(2].opid = 1d_hst[1].opid; 

id_list[2].tname = id_list[1].tname; 

id_list[2].exp_env = id_list{1].exp_env; 

id_list{2].count = id_hst[1].exp_envGid_list[1].count + 1) <>" 
-> id_list[1].count + 1 
# id_list[1].count; 


id_list[1].out_env = 
(id_list[1].action_code == "by_all” 
-> {((ID.%text4"BUFF_TYPE"):"fifo")} +! id_hst[2].out_env 


# id_list[1].action_code == "by_some” 
-> {(ID.%text*"BUFF_TYPE"):"sampled")} +! 1d_list[2].out_env 


# id_list[1].action_code == “input” 

-> {(ID.%text4"TYPE"):id_hist[ 1].tname) 
(ID.%text*"CONSTRUCT"):"data_stream") 
(ad_hst[1].opid*"INPARM"):[ID.%text,",", 

id_list{2].out_env(id_list[2].opid*"INPARM")]) 
} +1 id_hst{2].out_env 


# id_list[1].action_code == "output" 
-> {(ID.%text*"TYPE"):id_list[1].tname) 
(ID. %text*"CONSTRUCT"):"data_stream”) 
(ad_list{1].opid*"OUTPARM"):[ID.%text,",”, 
id_list{2].out_env(id_list[2].opid*"OUTPARM")]) 
} +1id_list[2].out_env 


# id_list[1].action_code == "stream" 


-> {(ID.%text4"TYPE"):id_list{1].tname) . 
(ID. %text*"CONSTRUCT"):"data_stream")} +1 id_list{[2].out_env 
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# 1d_list{1].action_code == "states" 
-> {(ID.%text4"TYPE"):id_list[1].tname) 
(ID. Ztext4A"CONSTRUCT"):"data_stream")} +1! id_list[2].out_env 


# id_list[1].action_code == "excp" 
-> {((ID. %text4"CONSTRUCT"):"exception”)} +! id_list{2].out_env 


# id_list[1].action_code == "tumer” 
-> {((ID.%text*"CONSTRUCT"):"tumer") } +1 id_list{2].out_env 


# id_list{1].action_code == "co_output’"’ 
-> {({id_list[{1].opid,"_",ID.%text,"OUTPUT"]:"conditional") } 
+1id_list[2].out_env 


# {(?:string:"")} 
D5 


id_list.ucond_output = 
(Gd_hist[1].in_env(Gid_hst[1].opid“"_"4ID.%text*"OQUTPUT") 
<> "conditional" ) && 
(id_list{1].action_code == "output") 
-> [id_list{1].in_envGd_list[1].opid“"PARENT"),"_SPEC.DS", 
ID.%text,".WRITEC',ID.%text,");\n"] 
wom 
) *id_hst{2].ucond_output; 


| ID 
{ id_list.trn = 
(id_list.acton_code == "input" II 
id_list.action_code == "output" 
-> (id_hist.in_env(Gid_hst.opid*"PARENT") == '"" 
-> ["package DS",ID.%text,” is new ", 
(id_list.in_env(ID.%text4" BUFF_TYPE") == "fifo" 

-> "FIFO_BUFFER" 
# "SAMPLED_BUFFER") 


Pal 


»"C'»,id_list.tname,"”);\n"} 

# ["package DS",ID.%text," renames ", 
id_list.in_env(id_list.opid“"PARENT"),"_SPEC.DS", 
ID.%text,";\n"]}) 


# id_list.action_code == "States" 
-> ["package DS" ID.%text," is new STATE_VARIABLE(", 
id_list.tname,”, ",id_list.exp_env(id_list.count), 
") An") 
# 1d_list.action_code == "excp" 
-> ["EX" ID. %text] 


# id_list.action_code == "stream" 
-> ["package DS", ID.%text," is new ", 
(id_list.in_envUID.%text*"BUFF_TYPE") == "fifo" 
-> "FIFO_BUFFER" 
# "SAMPLED BUFFER"), "(",id_list.tname,”);\n"] 


# id_list.action_code == "timer" 
=> | Tie ID Ziext| 


# id_list.action_code == "by_all” 
-> [id_list.opid,"_SPEC.DS",ID.%text,". NEW_DATA"] 


# id_list.action_code == "by_some” 
-> {id_list.opid,"_SPEC.DS",ID.%text,". NEW_DATA"] 


# id_list.action_code == "co_output" 
-> [{id_list.in_env(id_list.opid“"PARENT"),"_SPEC.DS" ID. %text, 
" WRITE(",ID.%text,");\n"] 
# aN 
id_list.out_env = 
(id_list.action_code == "by_all" 
-> {(ID.%text4"BUFF_TYPE"):"fifo") } 


# id_list.action_code == "“by_some” 
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-> {((ID.%text*"BUFF_TYPE"):"sampled")} 


# id_list[1].action_code == "input" 
-> {(ID.%text4"TYPE"):id_list[1].tname) 
(ID.%text*"CONSTRUCT"):"data_stream”") 
((id_list.opid“"INPARM"):ID.%text) } 


# id_list[1].action_code == "output" 
-> {(ID.%text4"TYPE"):1d_list[1].tname) 
(ID. %text4"CONSTRUCT"):"data_stream”") 
((id_list.opid*"OUTPARM"):ID. %text) } 


# id_list[1].action_code == "stream" 
-> {(ID.%text4"TYPE"):id_list[1].tname) 
(ID.%text4"CONSTRUCT"):"data_stream")} 
# id_list[1].action_code == "'states" 
-> {(((ID.%text® TYPE"):id_list{1].tname) 
(ID.%text*""CONSTRUCT"):"data_stream")} 


# id_list.action_code == "excp" 
-> {(ID.%text*"CONSTRUCT"):"exception")} 


# id_list.action_code == "timer'' 
-> {(ID.%text4"CONSTRUCT"):"timer") } 


# id_list.action_code == "co_output’ 
-> {({id_list.opid,"_",ID.%text,"OUTPUT"]:"conditional")} 


# ((?:string:"")} 
E 


id_list.ucond_output = 
((id_list.in_env(id_list.opid*"_"AID. %text4"OUTPUT")<>"conditional”) 
&& (id_list.action_code == "output") 
-> [id_list.in_envGd_list.opid*"PARENT"),"_SPEC.DS",ID.%text, 
"WRITE(" ID.%text,");\n"} 
ran 


); 
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time 
: INTEGER_LITERAL unit 
{ time.trn ="; } 


unit 
: MS 
{ unit.value = 1; 


[SEC 
{ unit.value = 1000; 


| MIN 
{ unit. value = 60000; 


| HOURS 
{ unit.value = 3600000; 
} 


reqmts_trace 
: BY id_list 
{ reqmts_trace.tmn = '"""; 
id_list.in_env = {(?:string:"")}; 
id_list.action_code = ""; 
id_list.tname = "": 


) 
TU 


id_list.opid = ""; 
id_list.count = 1; 
id_list.exp_env = {(?:int:"")}; 
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| 
{ reqmtsetrace.trn = ""; } 


> 


functionality 
: keywords informal_desc formal_desc 
{ functionality.tm =""; } 


keywords 
> KEYWORDS id_list 
{ keywords.tm = ""; 
id_list.in_env = {(?:string:"")}; 


id_list.action_code = ""; 


id_list.tname = ""; 
id_list.opid = ""; 
id_list.count = 1; 


id list-expwenv = {(?:nt:"")}; 


| 
{ keywords.trn = '""; } 


informal_desc 
: DESCRIPTION TEXT 
{ informal_desc.trn = '\n"; } 


{informal_desc.trn ="; } 


formal_desc 
: AXIOMS TEXT 
{ formal_desc.trn = '\n"; } 
{ formale@esc tm = ""; } 


type_imp]l 


| a 


: IMPLEMENTATION ADA ID 
{ type_impl.trn = ["procedure ",ID.%text," is;\n"]; } 
| IMPLEMENTATION type_name op_imp]_0_list END 
{ type_impl.tm = ['\n package DATA_TYPES is \n",type_name.trn,'\n", 
op_imp]_0_list.trn,'\n", 
"end;\n"]; } 


op_impl_0O_list 
: op_imp]_0_list OPERATOR ID operator_imp] 
{ OplimpleOnhstitan—. 
operator_impl.opid = ID.%text; } 
| 
{ op_imp]_0_list[1].trn ="; } 


operator_imp]l 
> IMPLEMENTATION ADA ID 
{ operator_impl.trn = ""; 
operator_impl.loc_ds_decl = ""; 
operator_impl.timer_decl = ""; 
operator_impl.out_env = {((ID.%text*"CONSTRUCT"):"atomic_operator”) }; 


| IMPLEMENTATION psdl_imp] 
{ operator_impl.trn = psdl_impl.trn; 
operator_impl.loc_ds_decl = psdl_imp].loc_ds_decl; 
operator_impl.timer_decl = psdl_impl.timer_decl:; 
psdl_impl.parent = operator_imp].opid; 
psdl_impl.in_env = operator_impl.in_env; 
psdl_impl.uncond_output_map = operator_impl.uncond_output_map; 
operator_imp].out_env = 
{ ((operator_imp].opid*"CONSTRUCT"):"composite_operator”) } +1 
psdl_impl.out_env; 


psdl_impl 
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: data_flow_diagram streams timers control_constraints informal_desc END 
{ psdl_impl.trn = control_constraints.tm; 

psdl_impl.out_env = streams.out_env +l control_constraints.out_env; 
psdl_impl.loc_ds_decl = streams.tm; 
psdl_impl.timer_decl = tmers.trn; 
data_flow_diagram.in_env = psdl_impl.in_env; 
streams.in_env = psdl_impl.in_env; 
control_constraints.parent = psdl_impl.parent; 
control_constraints.in_env = psdl_impl.in_env; 
control_constraints.decl_map = data_flow_diagram.decl_map; 
control_constraints.uncond_output_map = psdl_impl.uncond_output_map; 


data_flow_diagram 
: GRAPH link_0_list 
{ data_flow_diagram.tm = ""; 
data_flow_diagram.decl_map = link_O_list.out_decls; 
link_O_list.in_decls = {(?:string:"")}; 
link_O_list.in_env = data_flow_diagram.in_env; 


link_O_list 
: link link_O_list 
unk O list(l}tim=""; 
link_O_list[1].out_decls = link_O_list[2].out_decls; 
link_O_list{[2].in_decls = link.out_decls; 
link.in_decls = link_O_list[1].1n_decls; 
link.in_env = link_O_list[1].1in_env; 
link_O_list[2]}.in_env = link_O_list[1].1n_env; 
} 
| 
{ link_O_list.trn = ""; 
link_O_list.out_decls = link_O_list.in_decls; 
} 


1A 


link 
:-ID ’.’ ID opt_time ARROW ID 
| jisel< een = 
link.out_decls = 
(link.in_decls(D[3].%text*ID[1].%text4"READ") == "dup" 
-> {(?:string:"")} 
# {((D[3].%text*"READ"):[link.in_decls(ID[3].%text4"READ"), 


link.in_env("PARENT"),"_SPEC.DS",ID[1].%text,".READ(",ID[1]}.%text, 
");\n"]) (ID[3].%texID[1].%text*"READ"):"dup") } 
) +l 


(ink.in_decls({ID[2].%text,"_",ID[1].%text]) == "dup" 

-> {(?:string:"")} 

# {((ID[2].%text:flink.in_decls(ID[2].%text), 
ID[1].%text," : ",link.in_envdD[1].%textA"TYPE"), 
"A\n")) ({ID[2].%text,"_",ID[1].%text]:"dup") } 

) + 


(link.in_decls({ID[3].%text,"_",ID[1].%text]) == "dup" 

-> {(?:string:"")} 

# {(ID[3].%text:[link.in_decls(D[3].%text), 
ID[(1].%text,” : ",link.in_envdD[1].%text*A"TY PE"), 
"\n")) ({ID[3].%text,"_" ID[1].%text]:"dup") } 

) +l link.in_decls; 


opt_time 

: ) tne 

{ opt_tme.tm = ""; } 
| 


{ opt_time.tm = '\n"; } 


streams 
: DATA_STREAM type_decl 
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{ streams.trn = type_decl.trn; 
streams.out_env = type_decl.out_env; 
type_decl.opid = ""; 
type_decl.action_code = "stream"; 
type_decl.in_env = streams.in_env; 

| 
{streams.trn = ""; 
streams.out_env = {(?:string:"")}; 


type_name 
: ID ’[’ type_decl ’]’ 
{ type_name.trn = [ID.%text,"[",type_decl.tmn,"]\n"]; 
type_decl.opid = ""; 
type_decl.action_code = "tname’’; } 
| ID 
{ type_name.trn = ID.%text; } 


timers 
: TIMER id_list 
{ timers.trn = [id_list.trn," : PSDL_TIMER;\n"); 
id_list.in_env = {(?:string:"")}; 
id_list.action_code = "timer"; 


ttt, 


id_list.tname = ""; 
id_list.opid = ""; 
id_list.count = 1; 


id_list.exp_env = {(?:int:"")}; 


| 
{timers.trn = ""; 


control_constraints 
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: CONTROL 
{ control_constraints.trn = ""; 
control_constraints.out_env = {(?:string:"")}; 


| CONTROL OPERATOR ID opt_tng opt_per opt_fin_w constraint_options 
more_constraints 
{control_constraints.tm = 

(control_constraints.in_env(ID.%text*"CONSTRUCT") 
== "composite_operator’ 

-> ["procedure ",control_constraints.in_env("PARENT"), 
ID.%text," is\n begin\n  null;\n end ", 
control_constraints.in_env("PARENT"),"_",ID.%text,";\n"] 


—_= 3 


# ["procedure ",control_constraints.in_env(’ PARENT"), 
" "ID.%text," is\n",control_constraints.decl_map(ID. %text), 
‘Nnbegin\n" ,opt_trig.streams_check, 
control_constraints.decl_map(ID.%text*"READ"), 
opt_trig.pred, 
(control_constraints.in_env(ID.%text*"PROCCALL") == "" 
-> [ID.%text,'";\n"] 
# [ID.%text,"(, 

control_constraints.in_env(D.%text“" PROCCALL") ,");\n"] 

De 
constraint_options.tm,'\n", 
control_constraints.uncond_output_map(ID.%text), 
opt_trig.end_if_pred,opt_tng.end_if_streams, 
“end ",control_constraints.in_env("PARENT"), 
ie AD) Sorex nn 

) * more_constraints.tm; 


opt_trig.in_env = control_constraints.in_env; 
constraint_options.in_env = control_constraints.in_env; 
constraint_options.opid = ID. %text; 
control_constraints.out_env = 
{(ID.%text*"PARENT"):control_constraints.parent) } 
+] opt_tng.out_env 
+! constraint_options.out_env 
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+| more_constraints.out_env; 


more_constraints.parent = control_constraints.parent; 
more_constraints.in_env = control_constraints.in_env; 
more_constraints.uncond_output_map = 
control_constraints.uncond_output_map; 
more_constraints.decl_map = control_constraints.decl_map; 


} 


ntet, 


{control_constraints.trn = ""; 
control_constraints.out_env = {(?:string:"")}; 


more_constraints 
: OPERATOR ID opt_tng opt_per opt_fin_w constraint_options 
more_constraints 
{more_constraints[1].trn = 
(more_constraints.in_env(ID.Z%text4" CONSTRUCT") == 
“composite_operator'’ 
-> ["procedure ",more_constraints[1]].in_env("PARENT"),"_", 
ID.%text," is\n begin\n null;\n end", 
more_constraints[1].1in_env('PARENT"),"_",ID.%text,";\n"J 


# [procedure ",more_constraints[1].1n_env("PARENT"), 
"_",ID.%text," is\n",more_constraints[1].decl_map,..%text), 
‘Nnbegin\n" ,opt_trig.streams_check, 
more_constraints.decl_map(ID.%text4"READ"), 
opt_trig.pred, 
(more_constraints[1].in_env(ID.%text*A"PROCCALL") == "" 
-> (ID. %text,";\n"J 
# [ID.%text,"(", 

more_constraints[1].in_env(ID.%text*" PROCCALL"),");\n"] 
), 
constraint_options.tm,'\n", 
more_constraints[1].uncond_output_map(ID.%text), 
opt_trig.end_if_pred,opt_trig.end_if_streams, 


13] 


“end ",more_constraints[1].in_env('PARENT"), 
"_" ID.%text,";\n"] 


)  more_constraints[2].trn; 


opt_trig.in_env = more_constraints.in_env; 
constraint_options.in_env = more_constraints.in_env; 
constraint_options.opid = ID. %text; 
more_constraints[1].out_env = 
{(ID.%text*"PARENT"):more_constraints.parent)} + 
opt_tng.out_env + 
constraint_options.out_env +1 
more_constraints[2].out_env; 
more_constraints[2].in_env = more_constraints[1].in_env; 
more_constraints[2].uncond_output_map = 
more_constraints[1].uncond_output_map; 
more_constraints[2].decl_map = more_constraints[1].decl_map; 


| 
{more_constraints.tm = ""; 
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more_constraints.out_env = {(?:string:"")} ; 


constraint_options 
: OUTPUT id_list IF predicate reqmts_trace constraint_options 
{ constraint_options[1].tm = 
[“if ",predicate.trn,'\nthen\n _",id_list.trn,"\nend if;\n", 
constraint_options[2].trn] ; 


constraint_options[2].opid = constraint_options[1].opid; 
constraint_options[2].in_env = constraint_options[1].in_env; 
constraint_options[1].out_env = id_list.out_env + 

constraint_options[2].out_env; 
predicate.in_env = constraint_options[1].in_env; 
id_list.in_env = constraint_options[1].in_env; 
id_list.action_code = "co_output”; 


2 


id_list.tname = "": 

id_list.opid = constraint_options.opid; 
id_list.count = 1; 

id_list.exp_env = {(?:int:"")}; 


| EXCEPTION ID opt_if_predicate reqmts_trace constraint_options 
{ constraint_options[1].trn = constraint_options[2].tm; 
constraint_options[1].out_env = constraint_options[2].out_env; 
constraint_options[2].opid = constraint_options[1].opid; 
constraint_options[2].in_env = constraint_options[1].in_env; 
opt_if_predicate.in_env = constraint_options[1].in_env; 


j 


|timer_op ID opt_if_predicate reqmts_trace constraint_options 
{ constraint_options[1].tm = 
[opt_if_predicate.if,timer_op.tm,"(", 
constraint_options[1].in_env("PARENT"),"_SPEC.TL",ID.%text, 
");\n" opt_if_predicate.end_if,constraint_options[2].trn]; 
constraint_options[1].out_env = constraint_options[2].out_env; 
constraint_options[2].opid = constraint_options[1].opid; 
constraint_options[2].1n_env = constraint_options[1].1n_env; 
opt_if_predicate.in_env = constraint_options[1]}.1n_env; 


ttt, 


{ constraint_options.trn = ""; 
constraint_options.out_env = {(?:string:"")}; 


opt_mg 
: TRIGGERED trigger opt_if_predicate reqmts_trace 
{ opt_tg.out_env = trigger.out_env; 
opt_trig.pred = opt_if_predicate.if; 
opt_tnig.end_if_pred = opt_if_predicate.end_if; 
opt_trig.streams_check = tngger.if; 
opt_tng.end_if_streams = tigger.end_if; 


ee 


trigger.in_env = opt_trig.in_env; 
opt_if_predicate.in_env = opt_trig.in_env; 


{opt_trig.out_env = _ string:"")}; 
opt_trig.pred = "" 

opt_trig.end_if rete 
opt_trig.streams_check = 
opt_trig.end_ t_ Streams = 


} 


ete, 
ett, 


tte, 


trigger 
: ALL id_list 
{ tigger.if = ["if ",id_list.trn,'\nthen\n"}; 
trigger.end_if = “end if;\n"; 
trigger.out_env = 1d_list.out_env; 
id_list.action_code = "by_all"; 
id list.tname =. 
id_list.opid = trigger.in_env("PARENT =F 
id_list.count = 1; 
id_list.exp_env = {(?:int:"")}; 


| SOME id_list 

{ tigger.if = ["if ",id_list.trn,'\nthen\n"); 
trigger.end_if = "end if;\n"; 
trigger.out_env = id_list.out_env; 
id_list.action_code = "by_some’”; 
id_list.tmame = ""; 
id_list.opid = trigger.in_env("PARENT"): 
id_list.count = 1; 
id_list.exp_env = {(?:int:"")}; 


| 
{ trigger.if = 
trigger. ms if = 


tter, 
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trigger.out_env = {(?:string:'"”)}; 


opt_per 
-PERIOD time reqmts_trace 
{ opt_per.trn = ‘\n"; } 
| 
{ opt_per.trn = ""; } 


? 


opt_fin_w 
: FINISH time reqmts_trace 
{ opt_fin_w.tm = '\n"; } 
| 
{ opt_fin_w.tm =p} 


$ 


timer_op 
> READ 
{ tmer_op.tmn = "PSDL_TIMER.READ"; } 
BRESET 
{ tmer_op.tm = "PSDL_TIMER.RESET"; } 
| START 
{ timer_op.trn = "PSDL_TIMER.START’; } 
FS TOP 
{ imer_op.tm = "PSDL_TIMER.STOP"; } 


opt_if_predicate 
: IF predicate 
{ opt_if_predicate.if = ["if ",predicate.trn,"\nthen\n"}; 
opt_if_predicate.end_if = "end if;\n"; 
predicate.in_env = opt_if_predicate.in_env; 


} 


iS 


tett, 


{opt_if_predicate.if = ""; 
opt_if_predicate.end_if = ""; 
} 


expression_list 
: expression 
{expression_list.trn = expression.trm; 
expression_list.exp_env = {(expression_list.count:expression.tm) 
(0:12s(expression_list.count)) 


CO 1nte a) | 


| expression ’,’ expression_list 
{expression_list[1].trn = 
[expression.tmn,',",expression_list[2].trn]; 
expression_list[1].exp_env = 
{(expression_list[1].count:expression.tr) } +1 
expression_list[2].exp_env; 


expression_list[2].count = expression_list[1].count + 1; } 


expression 
: INTEGER_LITERAL 
{expression.tm = INTEGER_LITERAL. %text; } 
| REAL_LITERAL 
{expression.tm = REAL_LITERAL.%text; } 
| STRING_LITERAL 
{expression.ttn = STRING_LITERAL.%text; } 


| TRUE 

{expression.tm = " true"; } 
| FALSE 

{expression.tm = " false "; } 
| ID 


{expression.tm = ID.%text; } 
| type_name ’.’ ID ’( expression_list ’)’ . 
{expression.trmn = [type_name.tm,ID.%text,"(",expression_list.trn, 
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Oe 
expression_list.count = 1; } 
predicate 
: relation 
{ predicate.tm = relation.tm; 
predicate.type = relation.type; 
relation.in_env = predicate.in_env; 


| relation AND predicate 


{ predicate[1].trn = [relation.trn," and ",predicate[2].trn]; 
predicate[1].type = ""; 


predicate[2].in_env = predicate[1].in_env; 


relation.in_env = predicate[1].in_env; 


| relation OR predicate 


{ predicate[1].trn = [relation.tm," or ",predicate[2].trn]; 
predicate[1].type ="; 


predicate[2].in_env = predicate[1].in_env; 


relation.in_env = predicate[1].in_env; 


relation 


simple_expression rel_op simple_expression 
{relation.trn = rel_op.tm; 


simple_expression[1].in_env = relation.in_env; 
simple_expression[2].in_env = relation.in_env; 


relation.type = 
(simple_expression[1].type == "timer" II 
simple_expression[2].type == "timer" 
-> "timer" 


# simple_expression[1].type == "excp" Il 


simple_expression[2].type == "“excp" 
x "excp 


re? 


rea 
); 

rel_op.left_op = simple_expression[1].trm; 

rel_op.right_op = simple_expression[2]}.tm; 

rel_op.parent = relation.in_env("PARENT"); 


rel_op.opn_type = 
(simple_expression[1].type == “tmer’ II 
simple_expression[2}.type == “tumer” 
-> "timer_op" 
# "“arithmetic™ 
J; 


| simple_expression 
{relation.tm = simple_expression.tm; 
relation.type = simple_expression.type; 
simple_expression.in_env = relation.in_env; 


} 


simple_expression 
: INTEGER_LITERAL unit 
{ simple_expression.trn = i2s(s2i7NTEGER_LITERAL. %text) 
* unit.value); 
simple_expression.type = "timer"; 
| sign INTEGER_LITERAL 
{ simple_expression.tmn = [sign.tm, INTEGER_LITERAL. %text]; 
simple_expression.type = ""; 
| sign REAL_LITERAL 
{ simple_expression.trn = [sign.tm,REAL_LITERAL. %text]; 
simple_expression.type = ""; 
| ID 
{simple_expression.trn = ID. %text; 
simple_expression.type = 
(simple_expression.in_env(ID.%text*" CONSTRUCT") == "timer" 
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-> 
# simple_expression.in_env(ID.%text*4" CONSTRUCT") 
); 
| STRING_LITERAL 
{simple_expression.tm = STRING_LITERAL. %text; 
simple_expression.type = °"; 
} 
|’C predicate ’)’ 
{simple_expression.tm = ["(",predicate.tm,")"]; 
simple_expression.type = predicate.type; 
predicate.in_env = simple_expression.in_env; 


} 
| NOT ID 
{simple_expression.tm = ["not ",ID.%text]; 
simple_expression.type = ""; 
} 


| NOT ’( predicate ’)’ 
{simple_expression.tm = ["not (",predicate.trn,")"]; 
simple_expression.type = ""; 
predicate.in_env = simple_expression.in_env; 

| TRUE 
{simple_expression.tm = " true"; 
simple_expression.type = ""; 

| FALSE 
{simple_expression.tm = " false "; 
simple_expression.type = °"; 
} 

| NOT TRUE 
{simple_expression.trn = [" not true "J; 
simple_expression.type = ""; 
} 

| NOT FALSE 
{simple_expression.tm = " not false "; 


simple_expression.type = ""; 


S59 


rel_op 


> > 


ss 
{rel_op.trn = 
(rel_op.opn_type == "umer_op" 
-> ["PSDL_TIMER\"<\"(",rel_op.left_op,",",rel_op.right_op,") "] 
# [rel_op.left_op," < ",rel_op.right_op] 
); 
as 
{rel_op.trn = 
(rel_op.opn_type == "timer_op" 
-> ["PSDL_TIMER.\">\"("",rel_op.left_op,",",rel_op.right_op,") "] 
# [rel_op.left_op," > ",rel_op.right_op] 
) 
yoy 
{rel_op.tm = 
(rel_op.opn_type == "timer_op" 
-> ["PSDL_TIMER\"=\"("",rel_op.left_op,",",rel_op.right_op,") "] 
# [rel_op.left_op," = ",rel_op.night_op] 
); 
Gabe 
{rel_op.tm = 
(rel_op.opn_type == "timer_op" 
-> ["PSDL_TIMER\\">=\"(",rel_op.left_op,",",rel_op.nght_op,") "] 
# [rel_op.left_op," >= ",rel_op.right_op] 
); 
Lea 
{rel_op.tm = 


(rel_op.opn_type == "timer_op" 
-> ["PSDL_TIMER\"<=\"("",rel_op.left_op,",",rel_op.right_op, ) °] 
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# [rel_op.left_op," <= ",rel_op.right_op] 
): 
} 


| NEQV 
{rel_op.trn = 
(rel_op.opn_type == "timer_op" 
-> ["PSDL_TIMER.\"/=\"(",rel_op.left_op,",",rel_op.right_op,”) "] 
# [rel_op.left_op," /= ",rel_op.right_op] 
); 


ag 

{rel_op.trn = 
(rel_op.right_op == "NORMAL" 
-> [rel_op.parent,""_SPEC.DS",rel_op.left_op,".IS_NORMAL "] 
# [rel_op.parent,"_SPEC.DS" rel_op.left_op, 

"IS_EXCEPTION(" rel_op.right_op,") "] 

); 

j 


sign 
27+ 
{sign.tm = "+ "; } 


Pe.” 


3 


{sign.tm = "-"; } 
| 
{sign.tm ="; } 


° 
? 


14] 


APPENDIX E. TRANSLATION TEMPLATES 


A. TL PACKAGE TEMPLATE 


with PSDL_SYSTEM; 
use PSDL_SYSTEM; 
package TL ts 


vn PSDL_ EXCEPTION i is $ (psdl_ excpl, me Th, e292, "Sa 4 excpN); 
excpl, excp2, ...,excpN : exception; 


procedure Atomic_Driver1; 


procedure Atomic_Driver?2; 


procedure Atomic_DriverJ; 





end TL; 


package body TL is 


Atomic procedures drawn from software base. 


PSDL operator specification packages. 


PSDL atomic operator driver procedures. ~ 





end TL; 
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B. PSDL OPERATOR SPECIFICATION PACKAGE TEMPLATE 


This package template guides the translation of PSDL specifications into Ada 
packages. The packages contain only the data stream and timer instantiations that 
are local to Current_Operator. Current_Operator is the name listed in the header of 
the PSDL specification. Specification packages are produced only for composite 


operators. 


with Parent_Operator_SPEC; — -- Current_Operator’s parent. 
use Parent_Operator_SPEC; 
package Current_Operator_SPEC is 


INPUT data stream instantiations. 


OUTPUT data stream instantiations. 


STATES data stream instantiations. 





DATA STREAM data stream instantiations. 


TIMER instantiations. 





end Current_Operator_SPEC; 
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C. PSDL ATOMIC OPERATOR DRIVER PROCEDURE TEMPLATE 


This template guides the construction of the procedure that is used to unplement 
an atomic PSDL operator. It umplements the Ada code necessary to simulate all of 
the control constraints on the operator. It also contains a procedure call to the code 
which implements the actual operator drawn from the software base. When imple- 
mented, it is these procedures that will serve as the interface between the static and 


dynamic schedules and the operators from the software base. 


with Current_Operator_SPEC; | 
procedure Parent_Operator_ Current "Operon is 


Data stream variable declarations. 





begin 
if Data_Trigger then 
Read input data streams. 


if Trigger Condition then 
Current_Operator (Paramenter_List); -- Atomic procedure call 


Control constraint implementations. 
Timer operations, 
exception operations, a 


conditional output operations 


Unconditional output statements. — 





end if; 
end if: 
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>xcepuon 
when Ada_Exceptions => 
Write to ones exception streams. 


_ when others => 


raise;  -- re-raise Ada exception vif a  comesponding PSDL ‘ian ae not 


=~ declared 





end Parent_Operator_Current_Operator; 
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